Multi-AZ en geautomatiseerde back-ups

Wanneer een failover plaatsvindt, werkt RDS de DNS-CNAME van het database-eindpunt bij zodat deze binnen ongeveer 60 seconden naar de stand-by verwijst. Je applicatie moet opnieuw verbinding maken nadat deze een verbroken TCP-verbinding heeft gedetecteerd. Zo beperk je de vertraging bij het opnieuw verbinden:

• Gebruik een korte DNS-TTL (RDS stelt deze doorgaans al in op 5 seconden)
• Implementeer exponentiële wachttijden met opnieuw proberen in je verbindingslogica
• Gebruik hulpmiddelen voor verbindingspooling, zoals RDS Proxy, die automatisch opnieuw verbinding maken

Een failover kan ook handmatig worden gestart voor onderhoud of wijzigingen van de instantieklasse. Als Multi-AZ is ingeschakeld, zijn upgrades daardoor mogelijk met vrijwel geen downtime.

Een veelvoorkomende verwarring in examens is het verschil tussen Multi-AZ (voor beschikbaarheid) en Read Replicas (voor schaalbaarheid). De belangrijkste verschillen:

• Multi-AZ-stand-by: synchrone replicatie, verwerkt geen leesverkeer, automatische failover, dezelfde regio
• Read Replica: asynchrone replicatie, verwerkt leesverkeer, geen automatische failover, kan zich in een andere regio bevinden

Multi-AZ verbetert de leesprestaties niet: de stand-by is niet toegankelijk voor query's. Als je zowel de beschikbaarheid wilt verbeteren als leesbewerkingen wilt schalen, gebruik je Multi-AZ op de primaire instantie en voeg je afzonderlijk Read Replicas toe.

RDS maakt automatisch dagelijks volledige databasesnapshots en legt elke 5 minuten transactielogboeken vast. Samen maken deze functies herstel naar een bepaald tijdstip (PITR) mogelijk voor elke seconde binnen de bewaartermijn van de back-ups. Je kunt de database herstellen naar de toestand op elk moment binnen die periode.

Geautomatiseerde back-ups zijn standaard ingeschakeld en kunnen 1 tot 35 dagen worden bewaard. Als je de bewaartermijn instelt op 0, worden geautomatiseerde back-ups (en PITR) uitgeschakeld. Het back-upvenster is een periode van 30 minuten die je opgeeft of die AWS tijdens daluren kiest.

Het back-upvenster is de periode waarin dagelijkse momentopnamen worden gemaakt. Tijdens dit venster kan opslag-I/O bij implementaties in één beschikbaarheidszone kort worden onderbroken. Bij implementaties in meerdere beschikbaarheidszones wordt de momentopname vanaf de standby gemaakt, waardoor de impact op de I/O van de primaire instantie wegvalt.

Het onderhoudsvenster is een afzonderlijke wekelijkse periode waarin AWS patches voor het besturingssysteem, kleine engine-upgrades en wijzigingen aan instanties toepast. Het is een aanbevolen werkwijze om beide vensters in perioden met weinig verkeer in te plannen en ervoor te zorgen dat ze elkaar niet overlappen.

Om naar een specifiek tijdstip te herstellen, herstelt RDS eerst de meest recente dagelijkse momentopname en speelt het daarna transactielogboeken af tot aan de aangevraagde tijdstempel. Het resultaat is een nieuwe DB-instantie — PITR overschrijft de broninstantie nooit. Zo krijgt je een veilig herstelpad dat de productie niet onderbreekt.

Nadat de herstelde instantie beschikbaar is, werk je de verbindingsreeks van je toepassing bij zodat deze naar het nieuwe eindpunt verwijst. Vervolgens controleer je de gegevensintegriteit en verwijder je het origineel als het herstel opzettelijk was. De gebruikelijke hersteltijd is evenredig aan de omvang van de database en de hoeveelheid logboeken sinds de laatste momentopname.

Naast geautomatiseerde back-ups kun je op elk moment handmatige momentopnamen maken. In tegenstelling tot geautomatiseerde back-ups vallen handmatige momentopnamen niet onder de bewaartermijn — ze blijven bestaan totdat je ze expliciet verwijdert.

Handmatige momentopnamen zijn ideaal om de toestand vast te leggen vóór een grote schemamigratie, een upgrade van een toepassing of aan het einde van een factureringscyclus voor archivering vanwege nalevingsvereisten. Je kunt handmatige momentopnamen ook delen met andere AWS-accounts of tussen regio's kopiëren voor herstel na calamiteiten.

Je kunt geautomatiseerde of handmatige momentopnamen naar een andere AWS-regio kopiëren voor herstel na calamiteiten. De kopie is een volledige momentopname die wordt opgeslagen in de S3-infrastructuur van de doelregio. Nadat de momentopname is gekopieerd, kun je in die regio een nieuwe RDS-instantie herstellen als je primaire regio niet beschikbaar is.

Momentopnamekopieën kunnen in de doelregio worden versleuteld, zelfs als de bron niet is versleuteld, en omgekeerd. Voor kopieën tussen regio's worden kosten voor gegevensoverdracht in rekening gebracht. Gebruik AWS Backup of een door EventBridge geactiveerde Lambda om periodieke kopieën van momentopnamen tussen regio's te automatiseren.

Amazon RDS Proxy bevindt zich tussen je toepassing en RDS en beheert pools van databaseverbindingen. Dit is vooral nuttig voor Lambda-functies die duizenden verbindingen met een korte levensduur kunnen openen en de verbindingslimiet van de database kunnen overschrijden. RDS Proxy multiplexeert verbindingen, zodat de database veel minder actieve verbindingen ziet.

Tijdens een Multi-AZ-failover houdt RDS Proxy toepassingsverbindingen vast en brengt het de databaseverbinding met de nieuwe primaire instantie opnieuw tot stand. Daardoor duurt het opnieuw verbinden van de toepassing seconden in plaats van minuten. RDS Proxy integreert ook met Secrets Manager om aanmeldingsgegevens te roteren zonder uitvaltijd voor de toepassing.

RDS biedt nu twee Multi-AZ-opties: Multi-AZ DB Instance (klassiek, één standby) en Multi-AZ DB Cluster (twee leesbare standby-instanties in verschillende beschikbaarheidszones). De clustermodus gebruikt semi-synchrone replicatie en staat leesverkeer op standby-instanties toe. Dit biedt hogere beschikbaarheid en betere schaalbaarheid voor lezen zonder afzonderlijke Read Replicas.

Voor het SAA-C03-examen wordt de klassieke Multi-AZ DB Instance het vaakst getoetst. Onthoud: Multi-AZ Cluster is de nieuwere optie waarbij standby-instanties leesbewerkingen kunnen uitvoeren, terwijl de klassieke standby dat niet kan.

In deze les heb je geleerd dat Multi-AZ synchrone replicatie naar een standby met automatische failover biedt binnen 60–120 seconden, dat geautomatiseerde back-ups PITR mogelijk maken naar elke seconde binnen de bewaartermijn (1–35 dagen), en dat handmatige momentopnamen onbeperkt blijven bestaan en tussen regio's kunnen worden gekopieerd voor herstel na calamiteiten. Hierna bekijken we Read Replicas voor het verdelen van leesverkeer en het verbeteren van de doorvoersnelheid voor lezen.