Multi-AZ und automatische Backups

Multi-AZ ist eine RDS-Funktion für hohe Verfügbarkeit, die automatisch ein synchrones Standby-Replikat in einer anderen Availability Zone innerhalb derselben Region bereitstellt. AWS verwaltet die Replikation transparent – Sie verbinden sich über einen einzigen DNS-Endpunkt, und RDS leitet den Datenverkehr an die primäre Instance weiter.

Wenn die primäre Instance aufgrund von Hardware-, Netzwerk- oder Betriebssystemproblemen ausfällt, führt RDS innerhalb von etwa 60–120 Sekunden automatisch ein Failover auf das Standby-Replikat durch. Ihre Anwendung stellt über denselben DNS-Endpunkt die Verbindung wieder her, der nun zur IP-Adresse des Standby-Replikats aufgelöst wird.

Sie können Multi-AZ beim Erstellen einer RDS-Instance oder durch Ändern einer vorhandenen Instance aktivieren. Wenn Sie Multi-AZ für eine laufende Instance aktivieren, erstellt AWS einen Snapshot der primären Instance, stellt ihn in einer zweiten AZ wieder her und synchronisiert ihn anschließend mithilfe der nativen Replikation der Engine. Dieser Vorgang kann zu einer kurzen Unterbrechung der I/O auf der primären Instance führen. Planen Sie ihn daher in einem Zeitraum mit geringem Datenverkehr oder nehmen Sie den Zeitpunkt des Wartungsfensters in Kauf.

Multi-AZ wird für alle RDS-Engines unterstützt, einschließlich MySQL, PostgreSQL, MariaDB, Oracle und SQL Server, und erfordert keine Änderungen auf Anwendungsebene.

Bei einem Failover aktualisiert RDS innerhalb von etwa 60 Sekunden den DNS-CNAME des DB-Endpunkts, sodass er auf das Standby-Replikat zeigt. Ihre Anwendung muss die Verbindung nach dem Erkennen eines Abbruchs der TCP-Verbindung wiederherstellen. So minimieren Sie die Verzögerung beim Wiederverbinden:

• Verwenden Sie eine kurze DNS-TTL (von RDS typischerweise bereits auf 5 Sekunden gesetzt).
• Implementieren Sie exponentielles Backoff mit Wiederholungsversuchen in Ihrer Verbindungslogik.
• Verwenden Sie Tools für Connection-Pooling wie RDS Proxy, die automatisch eine neue Verbindung herstellen.

Ein Failover kann auch manuell für Wartungsarbeiten oder Änderungen der Instance-Klasse ausgelöst werden. Dadurch sind bei aktiviertem Multi-AZ-Upgrades mit nahezu keiner Ausfallzeit möglich.

In Prüfungen werden Multi-AZ (für Verfügbarkeit) und Read Replicas (für Skalierbarkeit) häufig verwechselt. Die wichtigsten Unterschiede:

• Multi-AZ-Standby: synchrone Replikation, stellt keinen Leseverkehr bereit, automatisches Failover, dieselbe Region
• Read Replica: asynchrone Replikation, stellt Leseverkehr bereit, kein automatisches Failover, kann sich in einer anderen Region befinden

Multi-AZ verbessert die Leseleistung nicht, da das Standby-Replikat für Abfragen nicht zugänglich ist. Wenn Sie sowohl die Verfügbarkeit verbessern als auch Lesevorgänge skalieren möchten, verwenden Sie Multi-AZ für die primäre Instance und fügen Sie separat Read Replicas hinzu.

RDS erstellt automatisch täglich vollständige Datenbank-Snapshots und erfasst alle 5 Minuten Transaktionsprotokolle. Zusammen ermöglichen diese Funktionen eine zeitpunktbezogene Wiederherstellung (PITR) auf jede beliebige Sekunde innerhalb des Aufbewahrungszeitraums für Backups. Sie können die Datenbank auf ihren Zustand zu jedem Zeitpunkt innerhalb dieses Zeitraums zurücksetzen.

Automatisierte Backups sind standardmäßig aktiviert und können 1 bis 35 Tage lang aufbewahrt werden. Wenn Sie den Aufbewahrungszeitraum auf 0 setzen, werden automatisierte Backups (und PITR) deaktiviert. Das Backup-Fenster umfasst 30 Minuten. Sie können es selbst festlegen oder AWS die Auswahl außerhalb der Spitzenzeiten überlassen.

Das Backup-Fenster ist der Zeitraum, in dem täglich Snapshots erstellt werden. Während dieses Fensters kann die Speicher-I/O bei Single-AZ-Bereitstellungen kurzzeitig pausieren. Bei Multi-AZ-Bereitstellungen wird der Snapshot vom Standby erstellt, sodass die I/O-Auswirkungen auf die primäre Instanz entfallen.

Das Wartungsfenster ist ein separater wöchentlicher Zeitraum, in dem AWS Betriebssystem-Patches, kleinere Engine-Upgrades und Änderungen an der Instance anwendet. Als Best Practice gilt, beide Fenster auf Zeiten mit geringem Datenverkehr zu legen und sicherzustellen, dass sie sich nicht überschneiden.

Um eine Wiederherstellung zu einem bestimmten Zeitpunkt durchzuführen, stellt RDS zunächst den aktuellsten täglichen Snapshot wieder her und spielt anschließend die Transaktionsprotokolle bis zum angeforderten Zeitstempel erneut ab. Das Ergebnis ist eine neue DB-Instance—PITR überschreibt niemals die Quell-Instance. Dadurch erhalten Sie einen sicheren Wiederherstellungspfad, der die Produktion nicht unterbricht.

Sobald die wiederhergestellte Instance verfügbar ist, aktualisieren Sie die Verbindungszeichenfolge Ihrer Anwendung so, dass sie auf den neuen Endpunkt verweist, überprüfen die Datenintegrität und löschen anschließend die ursprüngliche Instance, sofern die Wiederherstellung beabsichtigt war. Die typische Wiederherstellungszeit ist proportional zur Datenbankgröße und zum Protokollvolumen seit dem letzten Snapshot.

Zusätzlich zu automatisierten Backups können Sie jederzeit manuelle Snapshots erstellen. Im Gegensatz zu automatisierten Backups unterliegen manuelle Snapshots nicht der Aufbewahrungsfrist—sie bleiben bestehen, bis Sie sie ausdrücklich löschen.

Manuelle Snapshots eignen sich ideal, um den Zustand vor einer größeren Schema-Migration, einem Anwendungs-Upgrade oder am Ende eines Abrechnungszeitraums zur gesetzeskonformen Archivierung festzuhalten. Sie können manuelle Snapshots auch für andere AWS-Konten freigeben oder sie zur Notfallwiederherstellung über Regions hinweg kopieren.

Sie können automatisierte oder manuelle Snapshots zur Notfallwiederherstellung in eine andere AWS-Region kopieren. Bei der Kopie handelt es sich um einen vollständigen Snapshot, der in der S3-Infrastruktur der Ziel-Region gespeichert wird. Nach dem Kopieren können Sie in dieser Region eine neue RDS-Instance wiederherstellen, falls Ihre primäre Region nicht verfügbar ist.

Snapshot-Kopien können am Ziel verschlüsselt werden, selbst wenn die Quelle unverschlüsselt ist, und umgekehrt. Für Kopien über Regions hinweg fallen Datenübertragungskosten an. Verwenden Sie AWS Backup oder eine durch EventBridge ausgelöste Lambda-Funktion, um regelmäßige Snapshot-Kopien über Regions hinweg zu automatisieren.

Amazon RDS Proxy befindet sich zwischen Ihrer Anwendung und RDS und verwaltet einen Pool von Datenbankverbindungen. Das ist besonders für Lambda-Funktionen nützlich, die möglicherweise Tausende kurzlebiger Verbindungen öffnen und das Verbindungslimit der Datenbank ausschöpfen. RDS Proxy multiplexiert Verbindungen, sodass die Datenbank deutlich weniger aktive Verbindungen sieht.

Während eines Multi-AZ-Failovers hält RDS Proxy die Anwendungsverbindungen aufrecht und stellt die Datenbankverbindung zur neuen primären Instanz wieder her. Dadurch verkürzt sich die Wiederverbindungszeit der Anwendung auf wenige Sekunden statt Minuten. RDS Proxy lässt sich außerdem in Secrets Manager integrieren, um Anmeldeinformationen ohne Anwendungsausfall zu rotieren.

RDS bietet inzwischen zwei Multi-AZ-Optionen: Multi-AZ DB Instance (klassisch, eine Standby-Instance) und Multi-AZ DB Cluster (zwei lesbare Standby-Instances in unterschiedlichen AZs). Der Clustermodus verwendet semi-synchrone Replikation und erlaubt Lesezugriffe auf den Standby-Instances. Dadurch bietet er eine höhere Verfügbarkeit und bessere Skalierbarkeit für Lesezugriffe, ohne separate Read Replicas zu benötigen.

Für die SAA-C03-Prüfung wird die klassische Multi-AZ DB Instance am häufigsten abgefragt. Denken Sie daran: Der Multi-AZ Cluster ist die neuere Option, bei der Standby-Instances Lesezugriffe bedienen können, während dies bei der klassischen Standby-Instance nicht möglich ist.

Testen Sie Ihr Verständnis der AWS-Solutions-Architect-Konzepte (SAA-C03) aus dieser Lektion.

In dieser Lektion haben Sie gelernt: Multi-AZ bietet synchrone Standby-Replikation mit automatischem Failover innerhalb von 60–120 Sekunden, automatisierte Backups ermöglichen PITR auf jede Sekunde innerhalb der Aufbewahrungsfrist (1–35 Tage), und manuelle Snapshots bleiben unbegrenzt bestehen und können zur Notfallwiederherstellung über Regions hinweg kopiert werden. Als Nächstes sehen wir uns Read Replicas an, um Lesezugriffe zu verteilen und den Lesedurchsatz zu erhöhen.