Vi hör denna fråga mycket:Vad är det med Amazon Aurora? När du ska fastställa den bästa hanterade databastjänsten för din organisation finns det flera faktorer att ta hänsyn till – och en röd tråd genom dem alla är hur mycket kontroll du behöver. Amazon lägger mycket vikt bakom sitt Aurora DBaaS-erbjudande, men – beroende på dina krav och prioriteringar – kan det vara bättre att välja att köra en databas som MariaDB på Amazon EC2 eller en annan, icke-Amazon-tjänst.
Här är fyra saker du förmodligen inte visste om Amazon Aurora.
En åldrande, föråldrad databas
Amazon Aurora 2.x använder en gammal version av MySQL 5.7.
Aurora 2.0.1 släpptes i februari 2018, med MySQL 5.7.12, som i sig släpptes i april 2016. Aurora 2.x använder fortfarande en gammal version av MySQL 5.7. Amazon publicerar dock inte längre underhållsversionen den använder. Detta borde inte komma som någon överraskning. Det har funnits över ett dussin MySQL-underhållsversioner sedan 5.7.12. Hur många av buggfixarna i dem har Amazon backporterat? 17... av hundratals.
- Aurora 2.02.0:Bug #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:Bugg #26225783
- Aurora 2.04.2:Bug #24829050
Om du kunde välja en ny databas, skulle du välja en som släpptes för över tre år sedan, en som saknar tre år av buggfixar, säkerhetskorrigeringar, förbättringar och nya funktioner?
Krävd driftstopp och avbrott
Aurora kräver driftstopp för underhåll. Även om visst underhåll är valfritt och kan skjutas upp på obestämd tid, krävs inte bara annat underhåll, såsom säkerhets- och tillförlitlighetskorrigeringar, utan resulterar i stillestånd under ett slumpmässigt 30-minuters underhållsfönster. Vidare resulterar databasuppgraderingar (d.v.s. databasmotoruppdateringar) i 20-30 sekunders driftstopp eftersom de utförs på varje databasinstans inom ett kluster samtidigt.
MariaDB Platform, å andra sidan, stöder rullande uppgraderingar med graciösa övergångar, vilket gör att DBA:er kan utföra underhåll utan driftstopp på begäran.
Utöver underhåll och uppgraderingar kan det ta upp till två minuter för Aurora att utföra en automatisk failover, vilket resulterar i mer stillestånd. Vidare resulterar automatisk failover i förlorade anslutningar, sessioner och transaktioner under flygning.
MariaDB Platform, till skillnad från Aurora, stöder multi-master klustring för att eliminera driftstopp på grund av ett oväntat fel. Dessutom stöder MariaDB Platform anslutningsmigrering, sessionsåterställning och transaktionsuppspelning för att säkerställa att oväntade fel inte påverkar applikationer.
Brist på företagssäkerhet
Aurora saknar många av de företagssäkerhetsfunktioner som förväntas av moderna databaser, inklusive en databasbrandvägg, dynamisk datamaskering, roller, nyckelrotation och TLS 1.3.
Aurora stöder Amazon Key Management Service, men det stöder inte nyckelrotation för en databasinstans. Snarare kan ett nyckelalias användas för att ändra nyckeln för nya databasinstanser. Som sådan, även om en ny nyckel läggs till, kommer befintliga databasinstanser att fortsätta att kryptera och dekryptera data med den gamla nyckeln.
MariaDB Platform stöder nyckelrotation, och när en ny nyckel läggs till kan den automatiskt omkryptera data med den nya nyckeln – vilket gör att den gamla nyckeln kan kasseras.
Aurora saknar den kraftfulla databasbrandväggen och dynamiska databasmaskeringsfunktioner som finns tillgängliga i MariaDB Platform, och eftersom Aurora är baserad på en gammal version av MySQL saknar den också roller. Dessutom är den begränsad till TLS 1.0, 1.1 och 1.2.
Den minsta gemensamma nämnaren
Aurora förser användare med en blottad databas skapad med hjälp av en cookie-cutter-mall avsedd att möta den minsta gemensamma nämnaren. Medan MariaDB Platform kan skala ut läsningar, skrivningar och lagringar med transparent sharding via Spider-lagringsmotorn, eller dra nytta av skriv- och utrymmesoptimerad lagring på SSD:er via MyRocks-lagringsmotorn (utvecklad av Facebook), har Aurora ingetdera. Den är begränsad till InnoDB-lagringsmotorn.
Sedan finns det distribuerad, kolumnär lagring och massivt parallell bearbetning med MariaDB ColumnStore. Det är ännu en lagringsmotor som inte är tillgänglig i Aurora. Även om Amazon skulle föreslå att du använder Aurora för transaktionsbearbetning och Redshift för analys, kan båda göras med MariaDB Platform – vilket möjliggör hybrid transaktions-/analytisk bearbetning (HTAP).
Utöver arbetsbelastningsoptimerade lagringsmotorer finns det många funktioner tillgängliga i MariaDB Platform som inte kan hittas i Aurora, inklusive Oracle Database-kompatibilitet (d.v.s. PL/SQL), tidstabeller, punkt-i-tid rollback, streaming change-data-capture , en Apache Kafka-producent, transparent läs/skrivdelning, kontrollbegränsningar, standardvärdeuttryck, vanliga tabelluttryck, setoperatorer, fönsterfunktioner, användardefinierade funktioner (skalär, aggregerad och fönster), sekvenser och mer.
Amazons egna erfarenheter av Aurora illustrerar vikten av övervägandena ovan. Strax efter att ha flyttat några av sina databaser till Aurora upplevde Amazon omfattande avbrott och andra databasproblem under Prime Day 2018. När Prime Day 2019 närmar sig önskar vi Amazon lycka till!