Amazon RDS – Multi-AZ

Amazon RDS Multi-AZ ist verfügbar für RDS für PostgreSQL, RDS für MySQL, RDS für MariaDB, RDS für SQL Server, RDS für Oracle und RDS für Db2. Amazon RDS Multi-AZ mit zwei lesbaren Standbys ist für RDS für PostgreSQL und RDS für MySQL verfügbar. Weitere Informationen dazu, wie Amazon Aurora durch die automatische sechsfache Speicherreplikation über drei Availability Zones eine verbesserte Verfügbarkeit bietet, finden Sie unter Amazon Aurora.

Für Single-AZ-Bereitstellungen, Multi-AZ-Bereitstellungen mit einer Standby-Instance und Multi-AZ-Bereitstellungen mit zwei lesbaren Standby-Instances gelten die Preise pro verbrauchter DB-Instance-Stunde vom Start einer DB-Instance bis zum Beenden oder Löschen. Teilweise DB-Instance-Stunden werden in Sekundenschritten mit einer Mindestgebühr von 10 Minuten nach einer abrechenbaren Statusänderung wie dem Anlegen, Starten oder Ändern der DB-Instance-Klasse abgerechnet.

Weitere Informationen zu den Preisen für Amazon RDS Multi-AZ finden Sie auf den Amazon RDS-Preisseiten.

Verwenden Sie die folgenden Benutzerhandbücher und Tutorials, um schnell mit Amazon RDS Multi-AZ zu beginnen.

Sehen Sie sich Sitzungen, Webinare und andere Videos an, um tief in Amazon RDS Multi-AZ einzutauchen.

Lesen Sie mehr über die neuesten Verbesserungen von Amazon RDS Multi-AZ und erfahren Sie ausführlich, wie Sie es für Ihre Amazon-RDS-Anwendungsfälle verwenden können. 

Erzielen Sie mit ProxySQL Ausfallzeiten von einer Sekunde oder weniger, wenn Sie Amazon-RDS-Multi-AZ-Bereitstellungen mit zwei lesbaren Standbys aktualisieren

Schnelle Umstellung mit PgBouncer auf Amazon-RDS-Multi-AZ-Bereitstellungen mit zwei lesbaren Standbys für PostgreSQL

Erzielen Sie eine Ausfallzeit von einer Sekunde oder weniger mit dem Advanced JDBC Wrapper Driver, wenn Sie Amazon-RDS-Multi-AZ-DB-Cluster aktualisieren

Führen Sie kleinere Versions-Upgrades mit einer Ausfallzeit von 1 Sekunde oder weniger mit Amazon-RDS-Proxy- und Amazon-RDS-Multi-AZ-Bereitstellungen mit zwei lesbaren Standbys durch

Datenkonsolidierung für analytische Anwendungen mithilfe logischer Replikation für Amazon-RDS-Multi-AZ-Cluster

Beste Strategien zur Erzielung einer hohen Leistung und Hochverfügbarkeit auf Amazon RDS für MySQL mit Multi-AZ-DB-Clustern

Verbessern Sie die Anwendungsleistung auf Amazon RDS für MySQL- und MariaDB-Instances sowie MySQL-Multi-AZ-DB-Clustern mit Optimized Writes

Wählen Sie die richtige Amazon-RDS-Bereitstellungsoption: Single-AZ-Instance, Multi-AZ-Instance oder Multi-AZ-Datenbank-Cluster

Multi-AZ mit Amazon RDS Custom für SQL Server konfigurieren

Stellen Sie mithilfe von Terraform-Modulen einen Amazon-RDS-für-PostgreSQL- und MySQL-Multi-AZ-DB-Cluster bereit

Neue Multi-AZ-Bereitstellungsoption für Amazon RDS für MySQL und PostgreSQL: Verbesserte Schreibleistung und schnelleres Failover

Wenn Sie Ihre DB-Instance zur Ausführung als Multi-AZ-Bereitstellung erstellen oder modifizieren, erzeugt und unterhält Amazon RDS automatisch synchron eine "Standby"-Replica in einer anderen Availability Zone. Updates Ihrer DB-Instance werden synchron über mehrere Availability Zones in der Standby-Datenbank repliziert, damit Ihre letzten Datenbank-Updates synchronisiert und gegen einen Ausfall der DB-Instance geschützt sind.

Während bestimmten geplanten Wartungs- bzw. Aktualisierungsarbeiten oder im unwahrscheinlichen Fall eines Ausfalls der DB-Instance oder der Availability Zone führt Amazon RDS automatisch einen Failover zur Standby-Datenbank aus, sodass die Schreib- und Lesevorgänge in Ihrer Datenbank unmittelbar nach dem Wechsel fortgesetzt werden können. Da der Namensdatensatz für Ihre DB-Instance gleich bleibt, kann Ihre Anwendung den Datenbankbetrieb ohne manuellen administrativen Eingriff fortsetzen. Mit Multi-AZ-Bereitstellungen ist die Replikation transparent. Sie interagieren nicht direkt mit dem Standby, der nicht für den Verkehr verwendet werden kann. Weitere Informationen zu Multi-AZ-Bereitstellungen finden Sie im Amazon-RDS-Benutzerhandbuch.

Availability Zones sind isolierte Standorte innerhalb einer Region, d. h., sie sind bei Ausfällen in anderen Availability Zones nicht betroffen. Jede Availability Zone wird auf ihrer eigenen physisch getrennten, unabhängigen Infrastruktur ausgeführt und ist auf hohe Zuverlässigkeit ausgelegt. Übliche Fehlerquellen wie Generatoren und Kühlanlagen werden nicht von mehreren Availability Zones geteilt. Die physische Trennung sorgt außerdem dafür, dass sogar bei äußerst seltenen Katastrophen wie Bränden, Stürmen oder Überflutungen nur eine Availability Zone betroffen ist. Availability Zones innerhalb derselben Region profitieren von einer Netzwerkverbindung mit niedrigen Latenzen.

Wenn Sie eine DB-Instance als Multi-AZ-Bereitstellung betreiben, steht die primäre Datenbank für Schreib- und Lesevorgänge in der Datenbank zur Verfügung. Zusätzlich dazu stellt Amazon RDS im Hintergrund eine "Standby"-Instance zur Verfügung, die eine stets aktuelle Replica der Primär-Instance darstellt. Bei Failover-Szenarios wird die Standby-Instance "hochgestuft". Nach dem Failover wird also die Standby-Instance zur Primär-Instance und nimmt dann Ihre Datenbank-Operationen entgegen. Zu keinem Zeitpunkt vor der Hochstufung interagieren Sie direkt mit der Standby-Instance (etwa bei Lesevorgängen). Wenn Sie den Lesedatenverkehr über die Kapazitätseinschränkungen einer einzelnen DB-Instance hinaus skalieren möchten, finden Sie weitere Informationen in den häufig gestellten Fragen zu Read Replicas.

Die Hauptvorteile einer Ausführung Ihrer DB-Instance als Multi-AZ-Bereitstellung sind die erhöhte Zuverlässigkeit und Verfügbarkeit der Datenbank. Dank ihrer erhöhten Verfügbarkeit und Fehlertoleranz sind Multi-AZ-Bereitstellungen die ideale Lösung für Produktionsumgebungen.

Wenn Sie Ihre DB-Instance als Multi-AZ-Bereitstellung ausführen, sind Ihre Daten im unwahrscheinlichen Fall, dass eine DB-Instance-Komponente ausfällt oder der Dienst in einer Availability Zone unterbrochen wird, sicher. Wenn beispielsweise ein Speicher-Volume Ihrer Primär-Instance ausfällt, initiiert Amazon RDS automatisch einen Failover zur Standby-Instance, wo all Ihre Datenbank-Updates in intakter Form vorliegen. Dies bietet also zusätzliche Datenbeständigkeit im Vergleich zu Standard-Bereitstellungen in einer einzelnen AZ: Hier wäre eine vom Benutzer angestoßene Wiederherstellung erforderlich, und Updates, die nach dem letztmöglichen Wiederherstellungszeitpunkt (in der Regel in den letzten fünf Minuten) durchgeführt wurden, stünden nicht zur Verfügung.

Beim Betrieb Ihrer DB-Instance als Multi-AZ-Bereitstellung profitieren Sie darüber hinaus von einer verbesserten Datenbankverfügbarkeit. Bei einem Ausfall einer Availability Zone oder DB-Instance wird die Verfügbarkeit lediglich für den Zeitraum beeinträchtigt, der für das automatische Failover benötigt wird. Die Verfügbarkeitsvorteile von Multi-AZ kommen auch bei geplanten Wartungen bzw. Aktualisierungen zum Tragen.

So werden I/O-Vorgänge in Ihrer Primär-Instance beispielsweise bei automatisierten Backups im von Ihnen bestimmten Backup-Fenster nicht mehr unterbrochen, da die Backups vom Standby-Replikat angefertigt werden. Im Fall von Patches oder Skalierungen der DB-Instance-Klasse werden diese Operationen zunächst auf dem Standby-Replikat vorgenommen, bevor das automatische Failover erfolgt. Das Ergebnis: Es kommt lediglich für die Dauer, die der automatische Failover in Anspruch nimmt, zu Einschränkungen der Verfügbarkeit.

Ein weiterer Vorteil, den die Ausführung Ihrer DB-Instance als Multi-AZ-Bereitstellung mit sich bringt, liegt darin, dass das DB-Instance-Failover automatisch erfolgt und keinen Verwaltungsaufwand mit sich bringt. Im Hinblick auf Amazon RDS bedeutet das, dass Sie die DB-Instance-Ereignisse nicht überwachen und keine manuelle Wiederherstellung der DB-Instance (über die APIs RestoreDBInstanceToPointInTime oder RestoreDBInstanceFromSnapshot) starten müssen, wenn es zu einem Ausfall in einer Availability Zone oder zu einem DB-Instance-Ausfall kommen sollte.
 

Aufgrund der synchronen Datenreplikation, die in Ihrem Auftrag durchgeführt wird, kann es zu erhöhten Latenzen im Vergleich zur standardmäßigen Bereitstellung einer DB-Instance in einer einzelnen Availability Zone kommen.

Um eine Multi-AZ-Bereitstellung für eine DB-Instance einzurichten, klicken Sie einfach auf die Option „Ja“ für „Multi-AZ-Bereitstellung“, wenn Sie eine DB-Instance mit der AWS-Managementkonsole starten.

Wenn Sie die Amazon-RDS-APIs verwenden, können Sie die API CreateDBInstance nutzen und den Parameter „Multi-AZ“ auf „true“ setzen. Um eine bestehende, standardmäßige DB-Instance (Single-AZ) in eine Multi-AZ-Bereitstellung zu konvertieren, modifizieren Sie die DB-Instance in der AWS-Managementkonsole oder verwenden Sie die API ModifyDBInstance und setzen Sie den Parameter „Multi-AZ“ auf „true“.
 

Für die Datenbank-Engines RDS für PostgreSQL, RDS für MySQL, RDS für MariaDB, RDS für SQL Server, RDS für Oracle und RDS für Db2 passiert Folgendes, wenn Sie Ihre Amazon-RDS-Instance von Single-AZ in Multi-AZ konvertieren möchten:

• Ein Snapshot Ihrer Primär-Instance wird erstellt.
• Eine neue Standby-Instance wird aus dem Snapshot in einer anderen Availability Zone erstellt.
• Die synchrone Replikation wird zwischen Primär- und Standby-Instances konfiguriert.
  

Als solches sollte es keine Ausfallzeiten geben, wenn eine Instance von Single-AZ in Multi-AZ konvertiert wird. Möglicherweise sehen Sie jedoch eine erhöhte Latenzzeit, während die Daten im Standby-Modus aktualisiert werden, um mit dem Primärsystem Schritt zu halten.

Bei Multi-AZ-Bereitstellungen erfolgt bei den meisten gängigen Ausfallszenarien nach deren Erkennen eine automatische Wiederherstellung durch Amazon RDS, sodass Sie ohne Verwaltungsaufwand Datenbankvorgänge schnellstmöglich fortsetzen können. Amazon RDS führt in den folgenden Szenarien automatisch ein Failover durch:

• Verlust der Verfügbarkeit in der primären Availability Zone
• Verlust der Netzwerkverbindung zur Primär-Instance
• Ausfall einer Datenverarbeitungseinheit in der Primär-Instance
• Speicherfehler in der Primär-Instance

Hinweis: Wenn für Multi-AZ-Bereitstellungen Vorgänge wie die Skalierung von DB-Instances oder System-Upgrades wie das Einspielen von Betriebssystem-Patches ausgelöst werden, werden diese zur Optimierung der Verfügbarkeit vor einem automatischen Failover zunächst auf das Standby-Replikat angewendet. Es kommt deshalb lediglich für die Dauer, die das automatische Failover in Anspruch nimmt, zu Einschränkungen der Verfügbarkeit. Beachten Sie, dass Amazon-RDS-Multi-AZ-Bereitstellungen kein automatisches Failover als Reaktion auf Datenbankoperationen durchführen, wie z. B. lang laufende Abfragen, Deadlocks oder Datenbankbeschädigungsfehler.

Ja. Amazon RDS veranlasst ein DB-Instance-Ereignis, um Sie über den automatischen Failover zu informieren. Durch Klicken in den Bereich "Events" der Amazon RDS-Konsole oder mithilfe der API DescribeEvents können Sie Informationen zu Ereignissen in Verbindung mit Ihrer DB-Instance aufrufen. Sie können auch den Service Amazon RDS Event Notifications so konfigurieren, dass Sie bei Eintreten eines bestimmten DB-Ereignisses benachrichtigt werden.

Der Failover wird automatisch von Amazon RDS durchgeführt, damit Sie den Datenbankbetrieb schnellstmöglich und ohne Verwaltungsaufwand wieder aufnehmen können. Bei einem Failover wechselt Amazon RDS einfach den anerkannten Namensdatensatz (CNAME) für Ihre DB-Instance, sodass auf die Standby-Replica verwiesen wird, das dadurch zur neuen Primär-Instance hochgestuft wird. Wir empfehlen Ihnen, sich an bewährte Methoden zu halten und eine Funktion auf der Anwendungsebene zu implementieren, über die gegebenenfalls erneut versucht wird, eine Datenbankverbindung herzustellen.

Failover-Vorgänge erfolgen entsprechend der Festlegung des Zeitraums zwischen dem Erkennen des Ausfalls auf der Primär-Instance und Fortsetzung von Transaktionen auf der Standby-Instance in der Regel binnen 1-2 Minuten. Die Dauer des Failovers kann auch davon abhängen, ob umfassende Transaktionen ohne Datenbank-Commit wiederhergestellt werden müssen. Für optimale Ergebnisse wird der Einsatz ausreichend großer Instance-Typen für Multi-AZ-Bereitstellungen empfohlen. AWS empfiehlt auch die Nutzung von bereitgestellten IOPS mit Multi-AZ-Instances zum Sicherstellen einer schnellen, berechenbaren und einheitlichen Durchsatzleistung.

Amazon RDS führt bei einer Vielzahl von Fehlerbedingungen automatisch ein Failover durch, ohne dass Benutzer eingreifen müssen. Zusätzlich bietet Amazon RDS eine Option zum Initiieren eines Failovers beim Neustarten Ihrer Instance. Sie können auf dieses Feature über die AWS-Managementkonsole oder über den API-Aufruf RebootDBInstance zugreifen.

Bei Multi-AZ-Bereitstellungen setzen Sie einfach den Parameter „Multi-AZ“ auf „true“. Die Erstellung der synchronen Standby-Replikation und das Failover werden automatisch abgewickelt. Das bedeutet, dass Sie die Availability Zone nicht auswählen können, in der Ihre Standby-Replica bereitgestellt wird, und auch nicht die Anzahl der verfügbaren Standby-Instances verändern können (Amazon RDS erzeugt eine dedizierte Standby-Replica für jede primäre DB-Instance). Die Standby-Replica kann auch nicht für das Akzeptieren von Datenbankleseaktivitäten konfiguriert werden. Weitere Informationen zu Multi-AZ-Konfigurationen.

Ja. Ihre Standby-Replica wird automatisch in einer anderen Availability Zone in derselben Region wie Ihre primäre DB-Instance bereitgestellt.

Ja, Sie können den Standort der aktuellen primären Instance mithilfe der AWS-Managementkonsole oder der DescribeDBInstances-API einsehen.

Availability Zones sind darauf ausgelegt, Netzwerkverbindungen mit niedrigen Latenzen für andere Availability Zones derselben Region bereitzustellen. Zusätzlich empfiehlt es sich eventuell, die Architektur Ihrer Anwendung und anderer AWS-Ressourcen mit Redundanzen über mehrere Availability Zones anzulegen, damit Ihre Anwendung bei einem Ausfall einer einzelnen Availability Zone geschützt ist. Bei Multi-AZ-Bereitstellungen ist dies auf Datenbankebene der Fall, ohne dass hierfür ein administratives Zutun Ihrerseits erforderlich ist.

Die Interaktion mit automatisierten Backups und DB-Snapshot-Funktionalität ist bei Standardbereitstellungen in einer Single-AZ- oder Multi-AZ-Bereitstellung identisch. Wenn Sie eine Multi-AZ-Bereitstellung betreiben, werden automatisierte Backups und DB-Snapshots mithilfe der Standby-Replica erstellt, um eine E/A-Unterbrechung in der Primär-Instance zu vermeiden. Beachten Sie, dass es bei Single-AZ- oder Multi-AZ-Bereitstellungen im Verlauf von Backups zu einer erhöhten E-/A-Latenz (für gewöhnlich wenige Minuten) kommen kann.

Auch das Auslösen von Wiederherstellungsvorgängen (zeitpunktbezogene Wiederherstellung oder Wiederherstellung aus einem DB-Snapshot) erfolgt bei standardmäßigen Single-AZ- und Multi-AZ-Bereitstellungen gleich. Neue DB-Instance-Bereitstellungen können mithilfe der APIs RestoreDBInstanceFromSnapshot oder RestoreDBInstanceToPointInTime erstellt werden. Diese neuen DB-Instance-Bereitstellungen können entweder Standard- oder Multi-AZ-Bereitstellungen sein, unabhängig davon, ob das Quell-Backup von einer standardmäßigen oder einer Multi-AZ-Bereitstellung aus initiiert wurde.