Vi hører dette spørgsmål meget:Hvad sker der med Amazon Aurora? Når du skal bestemme den bedst administrerede databasetjeneste til din organisation, er der flere faktorer at overveje – og en rød tråd gennem dem alle er, hvor meget kontrol du har brug for. Amazon kaster en masse vægt bag sit Aurora DBaaS-tilbud, men - afhængigt af dine krav og prioriteter - kan det være en bedre løsning for dig at vælge at køre en database som MariaDB på Amazon EC2 eller en anden, ikke-Amazon-tjeneste.
Her er fire ting, du sandsynligvis ikke vidste om Amazon Aurora.
En aldrende, forældet database
Amazon Aurora 2.x bruger en gammel version af MySQL 5.7.
Aurora 2.0.1 blev udgivet i februar 2018 ved hjælp af MySQL 5.7.12, selv udgivet i april 2016. Aurora 2.x bruger stadig en gammel version af MySQL 5.7. Amazon udgiver dog ikke længere den vedligeholdelsesversion, den bruger. Dette burde ikke komme som nogen overraskelse. Der har været over et dusin MySQL-vedligeholdelsesudgivelser siden 5.7.12. Hvor mange af fejlrettelserne i dem har Amazon backporteret? 17... ud af hundreder.
- Aurora 2.02.0:Fejl #22833364
- Aurora 2.02.3:Bugs #24929748, #26867509, #22843444, #25080442
- Aurora 2.03.0:Bugs #24929748, #26867509, #22843444, #25080442
- Aurora 2.03.3:Bugs #25361251, #26734162, #27460607, #22343910, #23074801, #25287633
- Aurora 2.04.0:Fejl #26225783
- Aurora 2.04.2:Fejl #24829050
Hvis du kunne vælge en ny database, ville du så vælge en, der blev udgivet for over tre år siden, en der mangler tre år med fejlrettelser, sikkerhedsrettelser, forbedringer og nye funktioner?
Påkrævet nedetid og afbrydelse
Aurora kræver nedetid for vedligeholdelse. Mens noget vedligeholdelse er valgfrit og kan udskydes på ubestemt tid, er anden vedligeholdelse såsom sikkerheds- og pålidelighedsrettelser ikke kun påkrævet, men resulterer i nedetid i løbet af et tilfældigt 30-minutters vedligeholdelsesvindue. Yderligere resulterer databaseopgraderinger (dvs. databasemotoropdateringer) i 20-30 sekunders nedetid, fordi de udføres på hver databaseinstans i en klynge på samme tid.
MariaDB Platform understøtter på den anden side rullende opgraderinger med yndefulde overgange, hvilket gør det muligt for DBA'er at udføre vedligeholdelse uden nedetid efter behov.
Ud over vedligeholdelse og opgraderinger kan Aurora tage op til to minutter at udføre en automatisk failover, hvilket resulterer i mere nedetid. Yderligere resulterer automatisk failover i mistede forbindelser, sessioner og transaktioner under flyvningen.
MariaDB Platform understøtter i modsætning til Aurora multi-master clustering for at eliminere nedetid på grund af en uventet fejl. Derudover understøtter MariaDB Platform forbindelsesmigrering, gendannelse af sessioner og genafspilning af transaktioner for at sikre, at uventede fejl ikke påvirker applikationer.
Manglende virksomhedssikkerhed
Aurora mangler mange af de virksomhedssikkerhedsfunktioner, der forventes af moderne databaser, herunder en databasefirewall, dynamisk datamaskering, roller, nøglerotation og TLS 1.3.
Aurora understøtter Amazon Key Management Service, men den understøtter ikke nøglerotation for en databaseinstans. Et nøglealias kan snarere bruges til at ændre nøglen for nye databaseforekomster. Som sådan, selvom en ny nøgle tilføjes, vil eksisterende databaseforekomster fortsætte med at kryptere og dekryptere data ved hjælp af den gamle nøgle.
MariaDB Platform understøtter nøglerotation, og når en ny nøgle tilføjes, kan den automatisk genkryptere dataene ved hjælp af den nye nøgle – hvilket gør det muligt at kassere den gamle nøgle.
Aurora mangler den kraftfulde databasefirewall og dynamiske databasemaskeringsfunktioner, der er tilgængelige i MariaDB Platform, og fordi Aurora er baseret på en gammel version af MySQL, mangler den også roller. Yderligere er det begrænset til TLS 1.0, 1.1 og 1.2.
Den mindste fællesnævner
Aurora giver brugerne en bare-bones-database oprettet ved hjælp af en cookie-cutter-skabelon beregnet til at opfylde den mindste fællesnævner. Mens MariaDB Platform kan udskalere læsning, skrivning og lagring med transparent sharding via Spider-lagringsmotoren eller drage fordel af skrive- og pladsoptimeret lagring på SSD'er via MyRocks-lagringsmotoren (udviklet af Facebook), har Aurora ingen af delene. Den er begrænset til InnoDB-lagringsmotoren.
Så er der distribueret, søjleformet lagring og massivt parallel behandling med MariaDB ColumnStore. Det er endnu en lagermotor, der ikke er tilgængelig i Aurora. Mens Amazon vil foreslå at bruge Aurora til transaktionsbehandling og Redshift til analyse, kan begge dele udføres med MariaDB Platform – hvilket muliggør hybrid transaktionel/analytisk behandling (HTAP).
Ud over workload-optimerede lagermotorer er der mange funktioner tilgængelige i MariaDB Platform, som ikke kan findes i Aurora, inklusive Oracle Database-kompatibilitet (dvs. PL/SQL), tidstabeller, punkt-i-tids rollback, streaming change-data-capture , en Apache Kafka-producent, gennemsigtig læse-/skriveopdeling, kontrolbegrænsninger, standardværdiudtryk, almindelige tabeludtryk, sætoperatorer, vinduesfunktioner, brugerdefinerede funktioner (skalar, aggregeret og vindue), sekvenser og mere.
Amazons egne erfaringer med Aurora illustrerer vigtigheden af ovenstående overvejelser. Kort efter at have flyttet nogle af deres databaser til Aurora, oplevede Amazon udbredte nedbrud og andre databaseproblemer under Prime Day 2018. Når Prime Day 2019 nærmer sig, ønsker vi Amazon held og lykke!