Info2soft verwendet Cookies, um Ihnen ein besseres und angenehmeres Surferlebnis auf unserer Website zu ermöglichen. Datenschutzerklärung
Wird geladen...
Von:
Das automatische Failover von AWS RDS ist eine integrierte Hochverfügbarkeitsfunktion, die aktiviert wird, wenn Ihre primäre Datenbankinstanz nicht mehr erreichbar ist. Amazon RDS stuft automatisch eine Standby-Replikation in einer anderen Verfügbarkeitszone (AZ) zur primären Instanz hoch – ohne manuellen Eingriff.
Automatisches Failover und Multi-AZ: Welcher Zusammenhang besteht?
Das automatische Failover funktioniert nur, wenn Multi-AZ aktiviert ist. Bei aktiviertem Multi-AZ stellt AWS eine synchrone Standby-Replikation in einer separaten Verfügbarkeitszone bereit und hält diese jederzeit mit der primären Instanz synchron.
Was löst das automatische Failover von AWS RDS aus?
RDS führt bei geringfügigen Störungen keinen Wechsel durch. Ein Failover wird nur initiiert, wenn AWS ein schwerwiegendes Problem mit der primären Instanz feststellt:
Das RDS-Failover ist keine einfache Wiederherstellung aus einem Backup. Es handelt sich um einen koordinierten Wechsel zwischen zwei separaten Infrastrukturumgebungen – entwickelt, um schnell und für Ihre Anwendung transparent abzulaufen.
Wenn Multi-AZ aktiviert ist, betreibt AWS eine primäre DB-Instanz und eine Standby-Instanz in zwei unterschiedlichen Verfügbarkeitszonen. Der Schlüssel zur Vermeidung von Datenverlusten ist die synchrone Replikation.
Jeder Schreibvorgang auf der primären Instanz wird gleichzeitig auf die Standby-Instanz geschrieben. Eine Transaktion wird erst bestätigt, nachdem beide Instanzen sie protokolliert haben – dadurch ist die Standby-Instanz jederzeit eine exakte, aktuelle Spiegelung der primären Instanz.
Der gesamte Wechsel dauert typischerweise 60 bis 120 Sekunden. Folgendes passiert dabei:
Sowohl Multi-AZ-Standby-Instanzen als auch Lesereplikate nutzen Datenreplikation – sie dienen jedoch unterschiedlichen Zwecken. Eine Verwechslung ist ein häufiger und kostspieliger Fehler.
Hier ein kurzer Vergleich, bevor wir ins Detail gehen:
| Merkmal | Multi-AZ-Standby | Lesereplikat |
|---|---|---|
| Hauptzweck | Hochverfügbarkeit & Failover | Skalierung von Lesezugriffen & Leistungssteigerung |
| Replikationstyp | Synchron (kein Datenverlust) | Asynchron (mögliche Verzögerung) |
| Abfragen möglich | Nein | Ja (nur Lesezugriff) |
| Failover | Automatisch per DNS-Aktualisierung | Manuelle Hochstufung (Standard-RDS) |
| Verfügbarkeitszonen | Immer eine andere AZ | Gleiche AZ, andere AZ oder andere Region |
Die Standby-Instanz ist ein passiver Knoten – Sie können keine Abfragen darauf ausführen oder sich direkt verbinden. Ihre einzige Aufgabe ist es, mit der primären Instanz synchron zu bleiben und im Fehlerfall automatisch die Arbeit zu übernehmen. Daher ist Multi-AZ die richtige Wahl, wenn Verfügbarkeit oberste Priorität hat.
Lesereplikate sind aktive Knoten, die Lesezugriffe übernehmen und die primäre Instanz entlasten. Sie eignen sich zur Skalierung, nutzen aber asynchrone Replikation – das bedeutet, dass im Fehlerfall das Risiko besteht, dass die neuesten Transaktionen noch nicht auf das Replikat übertragen wurden.
Bei Standard-RDS-Engines (MySQL, PostgreSQL, Oracle) gibt es keine automatische Hochstufung von Lesereplikaten. Wenn die primäre Instanz ausfällt, müssen Sie die Hochstufung und DNS-Änderungen manuell durchführen – das bedeutet längere Ausfallzeiten im Vergleich zu Multi-AZ.
Das automatische Failover von AWS RDS funktioniert gut – innerhalb von AWS. Viele Unternehmensumgebungen sind jedoch nicht ausschließlich cloudbasiert. Wenn Ihre Infrastruktur lokale Server, VMware-Plattformen und öffentliche Clouds umfasst, hinterlässt eine rein cloudbasierte Failover-Lösung Lücken in Ihrem Schutz.
An dieser Stelle kommt i2Availability ins Spiel. Es handelt sich um eine anwendungsbezogene Hochverfügbarkeitslösung für komplexe heterogene Umgebungen – es erweitert das Disaster Recovery über die Möglichkeiten nativer Cloud-Tools hinaus.
AWS RDS handhabt Failover innerhalb seines eigenen Ökosystems effizient. Für Unternehmen mit Datenbanken in gemischten Umgebungen oder strengeren Compliance- und Wiederherstellungsanforderungen bietet i2Availability eine zusätzliche Ebene an Kontrolle und Flexibilität, die reine Cloud-native Tools nicht bereitstellen können.
Die Aktivierung von Multi-AZ ist nur der erste Schritt. Ohne passende Einstellungen für Anwendung und Infrastruktur kann Ihre Anwendung auch nach Wiederherstellung der Datenbank nicht erreichbar bleiben.
Während eines RDS-Failovers werden alle bestehenden Verbindungen zur primären Instanz getrennt. Ihre Anwendung gibt wahrscheinlich Fehler wie „Verbindung durch Peer zurückgesetzt“ oder „Kommunikationsverbindung fehlgeschlagen“ aus.
Zwei Maßnahmen sollten implementiert werden:
Verbindungspool-Tools wie PgBouncer oder HikariCP verbessern die Leistung, können aber während eines Failover nachteilig wirken, wenn sie nicht korrekt konfiguriert sind.
Warten Sie nicht auf Benutzerbeschwerden, um von einem Failover zu erfahren. Richten Sie eine proaktive Alarmierung ein:
Ein echter Ausfall ist der falsche Zeitpunkt, um Konfigurationslücken zu entdecken. Führen Sie regelmäßige Failover-Übungen durch:
F1: Verfügt RDS über ein automatisches Failover?
Ja, aber nur, wenn Multi-AZ aktiviert ist. AWS überwacht Ihre primäre Instanz und wechselt automatisch zu einer Standby-Replikation in einer anderen Verfügbarkeitszone, wenn ein Ausfall festgestellt wird.
F2: Was ist der Unterschied zwischen manuellem und automatischem Failover?
Ein automatisches Failover wird von AWS ausgelöst, wenn Hardware- oder Netzwerkfehler erkannt werden – ohne menschliches Zutun. Ein manuelles Failover wird vom Benutzer initiiert, meist über die Option „Neustart mit Failover“ in der AWS-Konsole, typischerweise für Tests oder geplante Wartungsarbeiten.
F3: Was löst ein RDS-Failover aus?
Häufige Auslöser sind ein Ausfall einer Verfügbarkeitszone, der Verlust der Netzwerkverbindung oder ein Hardwareausfall des Hosts. In einigen Fällen führt AWS während des Wartungsfensters auch einen geplanten Wechsel durch – beispielsweise bei Betriebssystem-Patches oder Instanz-Skalierung – dieser verhält sich ähnlich, wird aber nicht durch einen Ausfall verursacht.
F4: Verfügt RDS über automatisierte Sicherungen?
Ja. Amazon RDS erstellt automatisch tägliche Momentaufnahmen und erfasst Transaktionsprotokolle. Diese ermöglichen eine Point-in-Time-Wiederherstellung (PITR), mit der Sie Ihre Datenbank zu jedem beliebigen Sekundenwert innerhalb Ihres konfigurierten Aufbewahrungszeitraums wiederherstellen können.
F5: Bietet Amazon RDS mit Multi-AZ eine automatische Failover-Funktion?
Ja. Bei aktiviertem Multi-AZ stuft RDS automatisch die Standby-Instanz hoch und aktualisiert den DNS-Endpunkt – typischerweise innerhalb von 60 bis 120 Sekunden – ohne jeglichen manuellen Eingriff.
Das Verständnis des automatischen Failovers von AWS RDS entscheidet darüber, ob es sich um einen kurzen Ausfall oder einen schwerwiegenden Betriebsunterbrechung handelt. Multi-AZ bietet synchrone Replikation und automatisierten DNS-Wechsel – das ist aber nur die Hälfte der Lösung.
Um ein wirklich widerstandsfähiges System aufzubauen, benötigt Ihre Anwendung zudem Wiederholungslogik, niedrige DNS-TTL-Einstellungen und regelmäßige Failover-Übungen. AWS übernimmt den Wechsel der Infrastruktur; Ihre Architektur bestimmt, wie schnell Ihre Benutzer wieder Zugriff erhalten.
Für Unternehmen mit Datenbanken in hybriden oder mehrplattformigen Umgebungen reicht das native Failover von AWS oft nicht aus. Tools wie i2Availability erweitern den Schutz über die Cloud hinaus – sie decken lokale Server, Virtualisierungsplattformen und Rechenzentrumsübergreifende Szenarien ab, für die RDS allein keine Lösung bietet.
