Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Bereitstellungen von Multi-AZ-DB-Instances für Amazon RDS Amazon RDS bietet Hochverfügbarkeit und Failover-Unterstützung für DB-Instances, die Multi-AZ-Bereitstellungen mit einer einzelnen Standby-DB-Instance verwenden. Diese Art der Bereitstellung wird als *Multi-AZ-DB-Instance-Bereitstellung* bezeichnet. Amazon RDS verwendet mehrere verschiedene Technologien, um Failover-Unterstützung bereitzustellen. Multi-AZ-Bereitstellungen für DB-Instances von MariaDB, MySQL, Oracle, PostgreSQL und RDS Custom für SQL Server verwenden die Failover-Technologie von Amazon. Microsoft SQL Server-DB-Instances verwenden SQL Server-Datenbankspiegelung (DBM) oder AlwaysOn-Verfügbarkeitsgruppen (AGs). Informationen zur Unterstützung von SQL Server-Versionen für Multi-AZ finden Sie unter [Multi-AZ-Bereitstellungen für Amazon RDS für Microsoft SQL Server](USER_SQLServerMultiAZ.md). Informationen zum Arbeiten mit RDS Custom für SQL Server für Multi-AZ finden Sie unter [Verwalten einer Multi-AZ-Bereitstellung für RDS Custom für SQL Server](custom-sqlserver-multiaz.md). Bei einer Multi-AZ-Bereitstellung einer DB-Instance 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 Availability Zones hinweg auf ein Standby-Replikat repliziert, um Datenredundanz bereitzustellen und Latenzspitzen während Systemsicherungen zu minimieren. Wenn Sie eine DB-Instance mit hoher Verfügbarkeit ausführen, kann dies die Verfügbarkeit bei geplanten Systemwartungen verbessern. Sie kann auch Ihre Datenbanken bei Ausfällen der DB-Instance und bei Nichtverfügbarkeit von Availability Zones schützen. Weitere Informationen über Availability Zones finden Sie unter [Regionen, Availability Zones und Local Zones ](Concepts.RegionsAndAvailabilityZones.md). **Anmerkung** Die Option für hohe Verfügbarkeit ist keine Skalierungslösung für schreibgeschützte Szenarien. Sie können kein Standby-Replikat verwenden, um Leseverkehr bereitzustellen. Um schreibgeschützten Datenverkehr bereitzustellen, verwenden Sie stattdessen einen Multi-AZ-DB-Cluster oder ein Lesereplikat. Weitere Informationen zu Multi-AZ-DB-Clustern finden Sie unter [Bereitstellungen von Multi-AZ-DB-Clustern für Amazon RDS](multi-az-db-clusters-concepts.md). Weitere Informationen über Lesereplikate finden Sie unter [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md). ![\[Anwendungsszenario für hohe Verfügbarkeit\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/images/con-multi-AZ.png) Sie können über die RDS-Konsole eine Multi-AZ-DB-Instance-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 für DB-Instances umwandeln, indem Sie die DB-Instance ändern und die Option „Multi-AZ“ angeben. Sie können auch eine Multi-AZ-DB-Instance-Bereitstellung mit der AWS CLI oder der Amazon RDS-API angeben. Verwenden Sie den Befehl [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html)oder [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)CLI oder den Vorgang [Create DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) or [Modify DBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) API. In der RDS-Konsole wird die Availability Zone des Standby-Replikats angezeigt (auch als sekundäre AZ bezeichnet). Sie können auch den [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html)CLI-Befehl oder den Vorgang [Describe DBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html) API verwenden, um die sekundäre AZ zu finden. DB-Instances, die Multi-AZ-DB-Instance-Bereitstellungen verwenden, können im Vergleich zu einer Single-AZ-Bereitstellung eine höhere Schreib- und Commit-Latenz aufweisen. Dies kann aufgrund der auftretenden synchronen Datenreplikation geschehen. Es kann zu einer Änderung der Latenz kommen, wenn bei Ihrer Bereitstellung ein Failover auf das Standby-Replikat erfolgt, obwohl es AWS für Netzwerkverbindungen mit niedriger Latenz zwischen Availability Zones konzipiert wurde. Für Produktionsworkloads empfehlen wir die Verwendung von bereitgestellten IOPS (Eingabe-/Ausgabevorgänge pro Sekunde) für eine schnelle, konsistente Leistung. Weitere Informationen zu DB-Instance-Klassen finden Sie unter [](Concepts.DBInstanceClass.md). # Konvertieren einer DB-Instance in eine Multi-AZ-Bereitstellung für Amazon-RDS Das Ändern einer DB-Instance in eine Multi-AZ-Bereitstellung verbessert die Verfügbarkeit, indem eine Standby-Instance in einer anderen Availability Zone hinzugefügt wird. Der Prozess verursacht nur minimale Ausfallzeiten, erfordert jedoch eine sorgfältige Planung in Bezug auf Speicher- und Leistungsaspekte. Diese Änderung verbessert die Fehlertoleranz und verkürzt die Wiederherstellungszeit im Fehlerfall, wodurch sie sich ideal für hochverfügbare Umgebungen eignet. Wenn Sie eine DB-Instance in einer Single-AZ-Bereitstellung haben und diese in eine Multi-AZ-DB-Instance-Bereitstellung ändern, führt Amazon RDS die folgenden Aktionen aus: 1. Erstellt einen Snapshot der Amazon Elastic Block Store (EBS) -Volumes der primären DB-Instance. 1. Erstellt neue Volumes für das Standby-Replikat aus dem Snapshot. Diese Volumes werden im Hintergrund initialisiert, und die maximale Volume-Leistung wird erreicht, nachdem die Daten vollständig initialisiert wurden. 1. Aktiviert die synchrone Replikation auf Blockebene zwischen den Volumes der primären und Standby-Replikate. **Wichtig** Das Erstellen einer Standby-DB-Instance aus einem Snapshot während der Konvertierung von Single-AZ zu Multi-AZ vermeidet Ausfallzeiten, kann jedoch die Leistung beeinträchtigen – insbesondere bei schreibintensiven Workloads. Die synchrone Replikation kann die I/O Latenz erhöhen und die Datenbankleistung beeinträchtigen. Vermeiden Sie es als bewährte Methode, eine Produktions-DB-Instance in eine Multi-AZ-DB-Instance zu konvertieren. Erstellen Sie stattdessen ein Lesereplikat, aktivieren Sie Backups darauf, konvertieren Sie es in eine Multi-AZ-Instance, laden Sie Daten in seine Volumes und befördern Sie es anschließend zur primären DB-Instance. Weitere Informationen finden Sie unter [Arbeiten mit DB-Instance-Lesereplikaten](USER_ReadRepl.md). Es gibt zwei Möglichkeiten, eine DB-Instance in eine Multi-AZ-DB-Instance-Bereitstellung zu ändern: **Topics** + [Sie können sie mit der RDS-Konsole in eine Multi-AZ-DB-Instance-Bereitstellung konvertieren.](#Concepts.MultiAZ.Migrating.Convert) + [Ändern einer DB-Instance zu einer Multi-AZ-DB-Instance-Bereitstellung](#Concepts.MultiAZ.Migrating.Modify) ## Sie können sie mit der RDS-Konsole in eine Multi-AZ-DB-Instance-Bereitstellung konvertieren. Sie können die RDS-Konsole verwenden, um eine DB-Instance in eine Multi-AZ-DB-Instance-Bereitstellung zu konvertieren. Sie können die Konvertierung nur mit der Konsole abschließen. Folgen Sie den Anweisungen unter, um die AWS CLI oder die RDS-API zu verwenden. [Ändern einer DB-Instance zu einer Multi-AZ-DB-Instance-Bereitstellung](#Concepts.MultiAZ.Migrating.Modify) **So konvertieren Sie die DB-Instance mit der RDS-Konsole in eine Multi-AZ-DB-Instance-Bereitstellung** 1. Melden Sie sich bei der an AWS-Managementkonsole und öffnen Sie die Amazon RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Wählen Sie im Navigationsbereich **Databases (Datenbanken)** und dann die DB-Instance, die Sie ändern möchten. 1. Wählen Sie unter **Actions** (Aktionen) die Option **Convert to Multi-AZ deployment** In Multi-AZ-Bereitstellung konvertieren aus. 1. Damit Änderungen sofort übernommen werden, wählen Sie die Option **Apply Immediately** (Sofort anwenden) auf der Bestätigungsseite aus. Die Auswahl dieser Option verursacht keine Ausfallzeiten, kann jedoch zur Beeinträchtigung der Leistung führen. Sie können die Aktualisierung auch im nächsten Wartungsfenster übernehmen. Weitere Informationen finden Sie unter [Verwenden der Einstellung „Planen von Änderungen“](USER_ModifyInstance.ApplyImmediately.md). 1. Wählen Sie **Convert to Multi-AZ** (In Multi-AZ konvertieren) aus. ## Ändern einer DB-Instance zu einer Multi-AZ-DB-Instance-Bereitstellung Sie können eine DB-Instance auf folgende Weise so ändern, dass sie Teil einer Multi-AZ-Bereitstellung ist: + Ändern Sie die DB-Instance mithilfe der RDS-Konsole und legen Sie die Einstellung **Multi-AZ deployment** (Multi-AZ-Bereitstellung) auf **Yes** (Ja) fest. + Rufen Sie mit dem AWS CLI den [modify-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-instance.html)Befehl auf und legen Sie die `--multi-az` Option fest. + Rufen Sie mithilfe der RDS-API den DBInstance Vorgang [Modify](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBInstance.html) auf und setzen Sie den `MultiAZ` Parameter auf`true`. Informationen zum Ändern einer DB-Instance finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md). 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 über -Ereignisse finden Sie unter [Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen](USER_Events.md). # Failover einer Multi-AZ-DB-Instance für Amazon RDS Wenn ein geplanter oder ungeplanter Ausfall Ihrer Multi-AZ-DB-Instance durch einen Infrastrukturdefekt resultiert, wechselt Amazon RDS automatisch zu einem Standby-Replikat in einer anderen Availability Zone. 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 Multi-AZ-DB-Instance neu starten. Weitere Informationen finden Sie unter [Eine DB-Instance DB-Cluster neu starten](USER_RebootInstance.md). 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 in der folgenden Tabelle beschriebenen Bedingungen eintritt: Sie können diese Failover-Gründe im Ereignisprotokoll einsehen. | Failover-Grund | Beschreibung | | --- | --- | | Das Betriebssystem, das der RDS-Datenbank-Instance zugrunde liegt, wird offline gepatcht. | Ein Failover wurde während des Wartungsfensters für einen Betriebssystem-Patch oder ein Sicherheitsupdate ausgelöst. Weitere Informationen finden Sie unter [Warten einer DB-Instance](USER_UpgradeDBInstance.Maintenance.md). | | Der primäre Host der RDS-Multi-AZ-Instance ist fehlerhaft. | Die Multi-AZ-DB-Instance-Bereitstellung hat eine beeinträchtigte primäre DB-Instance erkannt und ein Failover eingeleitet. | | Der primäre Host der RDS-Multi-AZ-Instance ist aufgrund des Verlusts der Netzwerkverbindung nicht erreichbar. | Die RDS-Überwachung hat einen Fehler bei der Erreichbarkeit des Netzwerks für die primäre DB-Instance festgestellt und ein Failover ausgelöst. | | Die RDS-Instance wurde vom Kunden geändert. | Eine Änderung der RDS-DB-Instance hat ein Failover ausgelöst. Weitere Informationen finden Sie unter [Ändern einer Amazon-RDS-DB-Instance](Overview.DBInstance.Modifying.md). | | Die primäre RDS-Multi-AZ-Instance ist beschäftigt und reagiert nicht. | Die primäre DB-Instance reagiert nicht. Wir empfehlen Folgendes: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.Failover.html) Weitere Informationen zu diesen Empfehlungen finden Sie unter [Überwachungstools für Amazon RDS](MonitoringOverview.md) und [Bewährte Methoden für Amazon RDS](CHAP_BestPractices.md). | | Das Speichervolumen, das dem primären Host der RDS-Multi-AZ-Instance zugrunde liegt, ist ausgefallen. | Die Multi-AZ-DB-Instance-Bereitstellung hat ein Speicherproblem der primären DB-Instance erkannt und ein Failover eingeleitet. | | Der Benutzer hat ein Failover der DB-Instance angefordert. | Sie haben die DB-Instance neu gestartet und **Neustart mit Failover** gewählt. Weitere Informationen finden Sie unter [Eine DB-Instance DB-Cluster neu starten](USER_RebootInstance.md). | Um festzustellen, ob Ihre Multi-AZ-DB-Instance erfolgreich ausgeführt wurde, können Sie Folgendes tun: + 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 [Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen](USER_Events.md). + Sie können Ihre DB-Ereignisse über die RDS-Konsole oder mittels API-Operationen anzeigen. + Zeigen Sie den aktuellen Status Ihrer Multi-AZ-DB-Instance-Bereitstellung mithilfe der RDS-Konsole oder API-Vorgänge an. 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](CHAP_BestPractices.md). ## 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. Sie erhalten die JVM-Standard-TTL, indem Sie den Eigenschaftswert [https://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html](https://docs.oracle.com/javase/7/docs/technotes/guides/net/properties.html) abrufen: ``` String ttl = java.security.Security.getProperty("networkaddress.cache.ttl"); ``` **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](https://docs.oracle.com/javase/tutorial/essential/environment/security.html) 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 `networkaddress.cache.ttl`-Datei `$JAVA_HOME/jre/lib/security/java.security` 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"); ``` # Multi-AZ-Failover mit zusätzlichen Speichervolumen Multi-AZ-Bereitstellungen unterstützen DB-Instances mit zusätzlichen Speichervolumes. Während eines Failovers führt RDS automatisch einen Failover zur Standby-Instance durch, wobei alle zusätzlichen Speichervolumes an die DB-Instance angehängt werden. Dieser Prozess gewährleistet Datenkonsistenz und Verfügbarkeit. Wenn Sie eine Multi-AZ-Bereitstellung für eine DB-Instance mit zusätzlichen Speicher-Volumes konfigurieren, repliziert Amazon RDS automatisch alle Volumes auf die Standby-Instance in einer anderen Availability Zone. Der replizierte Speicher umfasst: + Das primäre Speichervolumen + Alle zusätzlichen Speichervolumes, die an Ihre DB-Instance angehängt sind Während eines Failovers bewirbt Amazon RDS die Standby-Instance und stellt sicher, dass alle Speichervolumes verfügbar und konsistent sind. Beim Failover wird dieselbe Speicherkonfiguration beibehalten, einschließlich Volume-Namen, Speichertypen und Leistungsmerkmalen. Nach einem erfolgreichen Failover können Sie anhand der Details zur Speicherkonfiguration überprüfen, ob alle Speichervolumes ordnungsgemäß angeschlossen sind und darauf zugegriffen werden kann. Weitere Informationen finden Sie unter [Details zum Speichervolumen für Ihre DB-Instance anzeigen](rds-storage-viewing.md). Die Failover-Zeit für DB-Instances mit zusätzlichen Speichervolumes ist ähnlich wie für DB-Instances mit nur primärem Speicher.