Multi-AZ och automatiska säkerhetskopior

Multi-AZ är en funktion för hög tillgänglighet i RDS som automatiskt provisionerar en synkron standbyreplika i en annan tillgänglighetszon inom samma region. AWS hanterar replikeringen transparent – ni ansluter via en enda DNS-slutpunkt och RDS dirigerar trafiken till primärinstansen.

Om primärinstansen slutar fungera på grund av problem med maskinvara, nätverk eller operativsystem utför RDS automatiskt en failover till standbyinstansen på ungefär 60–120 sekunder. Applikationen ansluter på nytt via samma DNS-slutpunkt, som nu pekar på standbyinstansens IP-adress.

Ni kan aktivera Multi-AZ när ni skapar en RDS-instans eller genom att ändra en befintlig instans. När funktionen aktiveras för en instans i drift tar AWS en snapshot av primärinstansen, återställer den i en andra tillgänglighetszon och synkroniserar sedan instanserna med motorns inbyggda replikering. Processen kan orsaka ett kort I/O-stopp på primärinstansen. Schemalägg den därför under en period med låg trafik eller acceptera tidpunkten för underhållsfönstret.

Multi-AZ stöds för alla RDS-motorer, inklusive MySQL, PostgreSQL, MariaDB, Oracle och SQL Server, och kräver inga ändringar på applikationsnivå.

När en failover inträffar uppdaterar RDS DNS CNAME-posten för DB-slutpunkten så att den pekar på standbyinstansen inom ungefär 60 sekunder. Applikationen måste ansluta på nytt när den upptäcker att en TCP-anslutning har brutits. Så här minimerar ni fördröjningen vid återanslutning:

• Använd en kort DNS-TTL (RDS har vanligtvis redan ställt in den på 5 sekunder)
• Implementera exponentiell backoff med återförsök i anslutningslogiken
• Använd verktyg för anslutningspoolning, till exempel RDS Proxy, som automatiskt ansluter på nytt

Failover utlöses även manuellt vid underhåll eller ändringar av instansklass, vilket möjliggör uppgraderingar med nästan inget driftstopp när Multi-AZ är aktiverat.

En vanlig förväxling på prov är skillnaden mellan Multi-AZ (för tillgänglighet) och Read Replicas (för skalbarhet). Viktiga skillnader:

• Multi-AZ-standby: synkron replikering, hanterar ingen lästrafik, automatisk failover, samma region
• Read Replica: asynkron replikering, hanterar lästrafik, ingen automatisk failover, kan finnas i en annan region

Multi-AZ förbättrar inte läsprestandan – standbyinstansen kan inte användas för frågor. Om ni både vill förbättra tillgängligheten OCH skala läsningar använder ni Multi-AZ för primärinstansen och lägger till Read Replicas separat.

RDS skapar automatiskt dagliga fullständiga databassnapshots och fångar upp transaktionsloggar var femte minut. Tillsammans möjliggör detta punkt-i-tid-återställning (PITR) till vilken sekund som helst inom säkerhetskopieringsperioden. Ni kan återställa databasen till dess tillstånd vid valfri tidpunkt under den perioden.

Automatiska säkerhetskopior är aktiverade som standard och kan behållas i 1 till 35 dagar. Om kvarhållningsperioden ställs in på 0 inaktiveras automatiska säkerhetskopior (och PITR). Säkerhetskopieringsfönstret är en period på 30 minuter som ni anger eller låter AWS välja under tider med låg belastning.

Säkerhetskopieringsfönstret är den tid då dagliga snapshots tas. Under det här fönstret kan lagrings-I/O tillfälligt pausas vid Single-AZ-distributioner. Multi-AZ-distributioner tar snapshoten från standby-instansen, vilket eliminerar påverkan på primärinstansens I/O.

Underhållsfönstret är en separat veckoperiod då AWS tillämpar OS-patchar, mindre motoruppgraderingar och ändringar av instansen. En beprövad metod är att förlägga båda fönstren till perioder med låg trafik och se till att de inte överlappar.

Om du vill återställa till en viss tidpunkt återställer RDS först den senaste dagliga snapshoten och spelar sedan upp transaktionsloggarna fram till den begärda tidsstämpeln. Resultatet blir en ny DB-instans – PITR skriver aldrig över källinstansen, vilket ger dig en säker återställningsväg som inte stör produktionen.

När den återställda instansen är tillgänglig uppdaterar du programmets anslutningssträng så att den pekar på den nya slutpunkten, verifierar dataintegriteten och tar sedan bort originalet om återställningen var avsiktlig. Den typiska återställningstiden är proportionell mot databasens storlek och loggvolymen sedan den senaste snapshoten.

Utöver automatiska säkerhetskopieringar kan du när som helst ta manuella snapshots. Till skillnad från automatiska säkerhetskopieringar omfattas manuella snapshots inte av bevarandetiden – de finns kvar tills du uttryckligen tar bort dem.

Manuella snapshots passar utmärkt för att spara tillståndet före en större schemamigrering eller en programuppgradering, eller i slutet av en faktureringsperiod för arkivering i efterlevnadssyfte. Du kan även dela manuella snapshots med andra AWS-konton eller kopiera dem mellan Regions för haveriberedskap.

Du kan kopiera automatiska eller manuella snapshots till en annan AWS Region för haveriberedskap. Kopian är en fullständig snapshot som lagras i målregionens S3-infrastruktur. När kopieringen är klar kan du återställa en ny RDS-instans i den regionen om din primära Region blir otillgänglig.

Snapshotkopior kan krypteras på destinationen även om källan är okrypterad, och omvänt. Kopiering mellan Regions medför kostnader för dataöverföring. Använd AWS Backup eller en Lambda-funktion som utlöses av EventBridge för att automatisera periodiska kopieringar av snapshots mellan Regions.

Amazon RDS Proxy fungerar mellan ditt program och RDS och hanterar pooler av databasanslutningar. Detta är särskilt användbart för Lambda-funktioner som kan öppna tusentals kortlivade anslutningar och överskrida databasens anslutningsgräns. RDS Proxy multiplexar anslutningar så att databasen ser betydligt färre aktiva anslutningar.

Vid en Multi-AZ-failover håller RDS Proxy kvar programmets anslutningar och upprättar databasanslutningen på nytt till den nya primärinstansen. Det minskar programmets återanslutningstid från minuter till sekunder. RDS Proxy integreras även med Secrets Manager för att rotera autentiseringsuppgifter utan driftstopp för programmet.

RDS erbjuder nu två Multi-AZ-alternativ: Multi-AZ DB Instance (klassisk, med en standby-instans) och Multi-AZ DB Cluster (två läsbara standby-instanser i olika AZ:er). Klusterläget använder semisynkron replikering och tillåter lästrafik på standby-instanserna, vilket ger högre tillgänglighet och bättre lässkalning utan separata Read Replicas.

I SAA-C03-provet testas den klassiska Multi-AZ DB Instance oftast. Kom ihåg: Multi-AZ Cluster är det nyare alternativet där standby-instanser kan hantera läsningar, medan den klassiska standby-instansen inte kan det.

I den här lektionen har du lärt dig att Multi-AZ tillhandahåller synkron standby-replikering med automatisk failover på 60–120 sekunder, att automatiska säkerhetskopieringar möjliggör PITR till vilken sekund som helst inom bevarandefönstret (1–35 dagar), och att manuella snapshots bevaras på obestämd tid och kan kopieras mellan Regions för DR. Nästa steg är Read Replicas, som används för att distribuera lästrafik och förbättra läskapaciteten.