Hohe Verfügbarkeit (Multi-AZ) für Amazon RDS - Amazon Relational Database Service

Hohe Verfügbarkeit (Multi-AZ) für Amazon RDS

Amazon RDS bietet durch Bereitstellung in mehreren Availability Zones hohe Verfügbarkeit und Failover-Unterstützung für DB-Instances. Amazon RDS verwendet mehrere verschiedene Technologien, um Failover-Unterstützung bereitzustellen. Multi-AZ-Bereitstellungen für MariaDB-, MySQL-, Oracle- und PostgreSQL-DB-Instances verwenden die Failover-Technologie von Amazon. SQL Server-DB-Instances verwenden die SQL Server-Datenbankspiegelung oder Always On-Verfügbarkeitsgruppen.

Bei einer Multi-AZ-Bereitstellung sorgt Amazon RDS für eine automatische Bereitstellung und Verwaltung eines synchronen Standby-Replikats in einer anderen Availability Zone. Die primäre DB-Instance wird synchron über mehrere Availability Zones in ein Standby-Replikat repliziert, um für Datenredundanz zu sorgen, das Einfrieren von E/A-Vorgängen zu vermeiden und Latenzspitzen im Verlauf von Systemsicherungen zu minimieren. Wenn Sie eine DB-Instance mit hoher Verfügbarkeit ausführen, kann dies die Verfügbarkeit bei geplanten Systemwartungen verbessern. Außerdem kann dies Ihre Datenbanken bei Ausfällen der DB-Instance und bei Nichtverfügbarkeit von Availability Zones schützen helfen. Weitere Informationen über Availability Zones finden Sie unter Regionen, Availability Zones und lokale Zonen .

Anmerkung

Das Hochverfügbarkeitsfeature ist keine Lösung zur Skalierung von schreibgeschützten Systemen: Sie können keine Standby-Replikate zum reinen Lesen von Datenverkehr verwenden. Zum reinen Lesen von Datenverkehr sollten Sie stattdessen ein Lesereplikat verwenden. Weitere Informationen finden Sie unter Arbeiten mit Lesereplikaten.


			Anwendungsszenario für hohe Verfügbarkeit

Sie können über die RDS-Konsole eine Multi-AZ-Bereitstellung erstellen, indem Sie ganz einfach bei der Erstellung einer DB-Instance die Option „Multi-AZ“ angeben. Sie können über die Konsole bestehende DB-Instances in Multi-AZ-Bereitstellungen umwandeln, indem Sie die DB-Instance ändern und die Option „Multi-AZ“ angeben. Sie können auch eine Multi-AZ-Bereitstellung mit der AWS CLI oder der Amazon RDS-API angeben. Verwenden Sie den CLI-Befehl create-db-instance oder modify-db-instance oder die API-Operation CreateDBInstance oder ModifyDBInstance.

In der RDS-Konsole wird die Availability Zone des Standby-Replikats angezeigt (auch als sekundäre AZ bezeichnet). Sie können auch den CLI-Befehl describe-db-instances oder die API-Operation DescribeDBInstances verwenden, um die sekundäre AZ zu suchen.

DB-Instances, die Multi-AZ-Bereitstellungen verwenden, können aufgrund der synchronen Datenreplikation im Vergleich zu einer Single-AZ-Bereitstellung eine erhöhte Schreib- und Commit-Latenz aufweisen. Die Latenz kann sich entsprechend ändern, wenn Ihre Bereitstellung ein Failover auf ein Standby-Replikat durchführt, obwohl AWS selbst mit einer Netzwerkanbindung zwischen Availability Zones mit einer geringen Latenz konzipiert ist. Für Workloads in Produktionsumgebungen empfehlen wir, bereitgestellte IOPS- und DB-Instance-Klassen zu verwenden, die für bereitgestellte IOPS-Instances mit konsistenter, hoher Leistung optimiert sind. Weitere Informationen zu DB-Instance-Klassen finden Sie unter DB-Instance-Klassen.

Ändern einer DB-Instance zu einer Multi-AZ-Bereitstellung

Wenn Sie eine DB-Instance in einer Single-AZ-Bereitstellung haben und diese in eine Multi-AZ-Bereitstellung ändern (für andere Engines als Amazon Aurora), führt Amazon RDS mehrere Schritte aus. Zuerst erstellt Amazon RDS einen Snapshot von der primären DB-Instance aus Ihrer Bereitstellung und stellt dann diesen Snapshot in einer anderen Availability Zone zur Verfügung. Dann richtet Amazon RDS eine synchrone Replikation zwischen Ihrer primären DB-Instance und der neuen Instance ein.

Informationen zum Ändern einer DB-Instance finden Sie unter Ändern einer Amazon RDS-DB-Instance.

Wichtig

Damit werden Ausfallzeiten bei der Umwandlung von Single-AZ in Multi-AZ vermieden, allerdings kommt es während und nach der Konvertierung in Multi-AZ zu Leistungseinbußen. Diese Einbußen können bei großen schreibintensiven DB-Instances erheblich sein.

Um Multi-AZ für eine DB-Instance zu aktivieren, erstellt RDS einen Snapshot des EBS-Volumes der primären DB-Instance und stellt ihn auf dem neu erstellten Standby-Replikat wieder her und synchronisiert dann beide Volumes. Aus vorhandenen EBS-Snapshots erstellte neue Volumes werden langsam im Hintergrund geladen. Mit dieser Funktion können große Volumes schnell aus einem Snapshot wiederhergestellt werden. Es besteht jedoch die Möglichkeit einer zusätzlichen Latenz während und nach Abschluss der Änderung. Weitere Informationen finden Sie unter Wiederherstellen eines Amazon EBS-Volumes aus einem Snapshot in der Amazon EC2-Dokumentation.

Nach Abschluss der Änderungen löst Amazon RDS ein Ereignis (RDS-EVENT-0025) aus, das anzeigt, dass der Prozess abgeschlossen ist. Sie können Amazon RDS-Ereignisse überwachen. Weitere Informationen zu Ereignissen finden Sie unter Verwenden von Amazon RDS-Ereignisbenachrichtigungen.

Failover-Prozess bei Amazon RDS

Bei einem geplanten oder ungeplanten Ausfall Ihrer DB-Instance schaltet Amazon RDS bei aktivierter Multi-AZ-Option automatisch auf ein Standby-Replikat in einer anderen Availability Zone um. Die Dauer, bis der Failover-Prozess für die Instance abgeschlossen ist, hängt von der Datenbankaktivität sowie von anderen Bedingungen zu dem Zeitpunkt ab, an dem die primäre DB-Instance ausgefallen ist. Der Failover-Prozess dauert normalerweise 60–120 Sekunden. Diese Failover-Dauer kann sich verlängern, wenn umfangreiche Transaktionen oder zeitintensive Wiederherstellungsprozesse durchgeführt werden. Wenn der eigentliche Failover-Prozess abgeschlossen ist, kann es noch einmal etwas dauern, bis die RDS-Konsole die Daten für die neue Availability Zone geladen hat.

Anmerkung

Sie können ein Failover manuell erzwingen, wenn Sie eine DB-Instance neu starten. Weitere Informationen finden Sie unter Neustarten einer DB-Instance.

Amazon RDS führt den Failover-Prozess automatisch durch, sodass der Datenbankbetrieb so schnell wie möglich und ohne Verwaltungseingriff wieder aufgenommen werden kann. Die primäre DB-Instance schaltet automatisch auf das Standby-Replikat um, wenn eine der folgenden Bedingungen eintritt:

  • Ausfall einer Availability Zone

  • Ausfall der primären DB-Instance

  • Änderung des Servertyps einer DB-Instance

  • Installation eines Softwarepatches auf dem Betriebssystem der DB-Instance

  • Manuelle Failover-Auslösung für die DB-Instance über die Option Neustart mit Failover

Sie können auf mehrere Weisen ermitteln, ob das Failover für Ihre Multi-AZ-DB-Instance erfolgreich durchgeführt wurde:

  • Sie können Benachrichtigungen per E-Mail oder per SMS für DB-Ereignisse abonnieren, bei denen ein Failover ausgelöst wird. Weitere Informationen über Ereignisse finden Sie unter Verwenden von Amazon RDS-Ereignisbenachrichtigungen.

  • Sie können Ihre DB-Ereignisse über die Amazon RDS-Konsole oder mittels API-Operationen anzeigen.

  • Sie können den aktuellen Status Ihrer Multi-AZ-Bereitstellungen über die Amazon RDS-Konsole oder mittels API-Operationen anzeigen.

Informationen zur empfohlenen Vorgehensweise bei Failover-Situationen, zur Verringerung der Wiederherstellungsdauer und zu bewährten Methoden für Amazon RDS finden Sie unter Bewährte Methoden für Amazon RDS.

Festlegen des JVM-TTL-Werts für DNS-Name-Lookups

Bei dem Failover-Prozess wird der DNS-Datensatz (Domain Name System) der DB-Instance so geändert, dass er auf die Standby-DB-Instance verweist. Als Ergebnis müssen alle bestehenden Verbindungen zu Ihrer DB-Instance neu hergestellt werden. In einer JVM-Umgebung (Java Virtual Machine) müssen Sie aufgrund der besonderen Funktionsweise der Zwischenspeicherung von DNS-Informationen in Java möglicherweise die JVM-Einstellungen rekonfigurieren.

Die JVM speichert DNS-Name-Lookups zwischen. Wenn die JVM einen Hostnamen zu einer IP-Adresse auflöst, speichert sie die IP-Adresse für einen bestimmten Zeitraum zwischen. Diese Zeit ist als Time-to-Live (TTL, Lebensdauer) bekannt.

Da AWS-Ressourcen DNS-Namenseinträge nutzen, die sich gelegentlich ändern, empfehlen wir, dass Sie Ihre JVM mit einem TTL-Wert von maximal 60 Sekunden konfigurieren. Auf diese Weise wird bei Änderung der IP-Adresse einer Ressource sichergestellt, dass Ihre Anwendung die neue IP-Adresse der Ressource durch erneute Abfrage des DNS abrufen und nutzen kann.

Bei einigen Java-Konfigurationen ist die JVM-Standard-TTL so festgelegt, dass DNS-Einträge nie aktualisiert werden, bis die JVM neu gestartet wird. Ändert sich die IP-Adresse einer AWS-Ressource also, während Ihre Anwendung läuft, kann die Anwendung die Ressource erst wieder nutzen, nachdem Sie die JVM manuell neu starten und die zwischengespeicherten IP-Informationen aktualisiert wurden. In diesem Fall ist es wichtig, die TTL der JVM so einzustellen, dass sie die zwischengespeicherten IP-Daten von Zeit zu Zeit aktualisiert.

Anmerkung

Die Standard-TTL kann je nach Version Ihrer JVM und abhängig davon, ob ein Sicherheits-Manager installiert ist, unterschiedlich sein. Viele JVMs bieten eine Standard-TTL von weniger als 60 Sekunden. Wenn Sie eine solche JVM und keinen Sicherheits-Manager nutzen, können Sie den Rest dieses Themas ignorieren. Weitere Informationen zu Sicherheits-Managern in Oracle finden Sie unter The Security Manager in der Oracle-Dokumentation.

Um die TTL der JVM zu ändern, legen Sie den Eigenschaftswert networkaddress.cache.ttl fest. Nutzen Sie dazu eine der folgenden Methoden je nach Ihrem Bedarf:

  • Legen Sie in der $JAVA_HOME/jre/lib/security/java.security-Datei networkaddress.cache.ttl fest, um den Eigenschaftswert global für alle Anwendungen festzulegen, die die JVM verwenden.

    networkaddress.cache.ttl=60
  • Um die Eigenschaft nur für Ihre Anwendung lokal festzulegen, legen Sie networkaddress.cache.ttl im Initialisierungscode Ihrer Anwendung fest, bevor Netzwerkverbindungen hergestellt werden.

    java.security.Security.setProperty("networkaddress.cache.ttl" , "60");