Welche Auswirkungen hat die Änderung meiner Single-AZ-Amazon-RDS-Instance in eine Multi-AZ-Instance und umgekehrt?

Kurzbeschreibung

In einem Single-AZ-Setup werden eine Amazon-RDS-DB-Instance und ein oder mehrere Amazon Elastic Block Store (Amazon EBS)-Speicher-Volumes in einer Availability Zones bereitgestellt. In einer Multi-AZ-Konfiguration werden die DB-Instances und EBS-Speicher-Volumes in zwei Availability Zones bereitgestellt.

Wenn Sie Multi-AZ auf Ihrer Instance aktivieren, verwaltet Amazon RDS eine redundante und konsistente Standby-Kopie Ihrer Daten mithilfe synchroner Speicherreplikation. Amazon RDS erkennt die häufigsten Infrastrukturfehlerszenarien für Multi-AZ-Bereitstellungen und stellt diese dann automatisch wieder her. Diese Erkennung und Wiederherstellung erfolgt, damit Sie den Datenbankbetrieb so schnell wie möglich wieder aufnehmen können. Weitere Informationen finden Sie unter Hochverfügbarkeit (Multi-AZ) für Amazon RDS.

Informationen zum Ändern einer DB-Instance von einer Single-AZ-Bereitstellung in eine Multi-AZ-Bereitstellung und umgekehrt finden Sie unter Ändern einer Amazon-RDS-Instance.

Auflösung

Auswirkungen der Änderung einer Single-AZ-Instance auf eine Multi-AZ-Instance

Wenn Sie Ihre Single-AZ-Instance in eine Multi-AZ ändern, kommt es zu keinen Ausfallzeiten auf der Instance. Während der Änderung erstellt Amazon RDS einen Snapshot der Instance-Volumes. Anschließend wird dieser Snapshot verwendet, um neue Volumes in einer anderen Availability Zone zu erstellen. Obwohl diese neuen Volumes sofort zur Verwendung verfügbar sind, kann es zu einer Leistungsauswirkung kommen. Diese Auswirkung tritt auf, weil die Daten des neuen Volumes immer noch aus Amazon Simple Storage Service (Amazon S3) geladen werden. In der Zwischenzeit lädt die DB-Instance weiterhin Daten im Hintergrund. Dieser als Lazy Loading bezeichnete Prozess kann zu einer erhöhten Schreiblatenz und Leistungsauswirkung während und nach dem Änderungsprozess führen.

Die Auswirkung auf die Leistung hängt von Ihrem Volume-Typ, Workload, Ihrer Instance und Volume-Größe ab. Die Auswirkung könnte für große schreibintensive DB-Instances während der Spitzenzeiten des Betriebs erheblich sein. Daher ist es eine bewährte Methode, die Auswirkung auf eine Test-Instance zu testen, bevor diese Änderung in der Produktion ausgeführt wird. Es ist auch eine bewährte Methode, diese Änderung in einem Wartungs- oder Niedrigdurchsatzfenster durchzuführen.

Die Ladedauer verkürzen

Verkürzen Sie die Dauer und die Auswirkung des Ladens proaktiv wie folgt:

1. Ändern Sie den Typ des DB-Instance-Speichers in bereitgestellte IOPS. Stellen Sie sicher, dass Sie eine Menge an IOPS bereitstellen, die erheblich höher ist als für Ihre Workload erforderlich.
   Hinweis: Dieser Schritt kann zu einer kurzen Ausfallzeit führen, wenn die Instance eine benutzerdefinierte Parametergruppe verwendet.
2. Ändern Sie die Instance auf Multi-AZ.
3. Initiieren Sie ein Failover auf Ihrer Instance, um sicherzustellen, dass die neue AZ die primäre AZ ist.
4. Führen Sie einen vollständigen Speicherauszug der Daten auf Ihrer Instance aus. Oder führen Sie vollständige Tabellenscan-Abfragen für die aktivsten Tabellen aus, um das Laden der Daten in die Volumes zu beschleunigen.
5. Vergewissern Sie sich, dass die Schreiblatenz wieder auf ein normales Niveau zurückgekehrt ist, indem Sie die Metrik WriteLatency in Amazon CloudWatch überprüfen.
6. Ändern Sie den Typ des Instance-Speichers oder die IOPS zurück auf Ihre vorherige Konfiguration.
   Hinweis: Für diesen Schritt sind keine Ausfallzeiten erforderlich.

Die Latenz reduzieren, wenn Ihre Instance bereits Multi-AZ ist

Gehen Sie wie folgt vor, um die Latenz zu reduzieren, wenn Sie die Instance bereits auf Multi-AZ geändert haben:

1. Initiieren Sie ein Failover auf Ihrer Instance, um sicherzustellen, dass die neue AZ die primäre AZ ist.
2. Ändern Sie den Typ des DB-Instance-Speichers in bereitgestellte IOPS. Stellen Sie sicher, dass Sie eine Menge an IOPS bereitstellen, die erheblich höher ist als für Ihre Workload erforderlich.
   Hinweis: Für diesen Schritt sind keine Ausfallzeiten erforderlich.
3. Führen Sie einen vollständigen Speicherauszug der Daten auf Ihrer Instance aus. Oder führen Sie vollständige Tabellenscan-Abfragen für die aktivsten Tabellen aus, um das Laden der Daten in die Volumes zu beschleunigen.
4. Vergewissern Sie sich, dass die Schreiblatenz wieder auf ein normales Niveau zurückgekehrt ist, indem Sie die Metrik WriteLatency in Amazon CloudWatch überprüfen.
5. Ändern Sie den Typ des Instance-Speichers oder die IOPS zurück auf Ihre vorherige Konfiguration.
   Hinweis: Für diesen Schritt sind keine Ausfallzeiten erforderlich.

Wenn Sie eine DB-Instance von Single-AZ in Multi-AZ ändern, wird eine Standby-Instance mit derselben Konfiguration in einer anderen Availability Zone erstellt. Dies führt zu zusätzlichen Kosten. Da Multi-AZ eine synchrone Replikation verwendet, sind Schreibvorgänge außerdem etwas langsamer als in Single-AZ.

Auswirkungen der Änderung einer Multi-AZ-Instance in eine Single-AZ-Instance

Wenn Sie Ihre Instance von Multi-AZ auf Single-AZ ändern, treten bei der Instance keine Ausfallzeiten auf. Während der Änderung löscht Amazon RDS nur die sekundäre Instance und Volumes, während die primäre Instance nicht davon betroffen ist.

Hier sind ein paar Dinge zu beachten, bevor Sie Ihre Instance von Multi-AZ zu Single-AZ-Bereitstellung ändern:

• Bei der Multi-AZ-Bereitstellung wechselt Amazon RDS während eines geplanten oder ungeplanten Ausfalls Ihrer DB-Instance automatisch zu einer Standby-Kopie in einer anderen Availability Zone. In einer Single-AZ-Instance müssen Sie jedoch möglicherweise einen Point-in-Time-Wiederherstellungsvorgang einleiten. Dieser Vorgang kann einige Stunden dauern. Daten-Updates, die nach dem letzten wiederherstellbaren Zeitpunkt erfolgt sind, sind nicht verfügbar. Daher kann es bei einer Single-AZ-Instance zu einer zusätzlichen Ausfallzeit kommen, falls ein Ausfall auftritt.
• In einer Multi-AZ-Instance werden automatisierte Backups von der sekundären Instance während des automatischen Backup-Fensters erstellt. Für Amazon RDS for MariaDB, Amazon RDS for MySQL, Amazon RDS for Oracle und Amazon RDS for PostgreSQL wird die I/O-Aktivität auf Ihrer primären Instance während des Backups für Multi-AZ-Bereitstellungen nicht ausgesetzt, da das Backup von der sekundären Instance stammt. Für Amazon RDS for SQL Server wird die I/O-Aktivität während des Backups für Multi-AZ-Bereitstellungen kurzzeitig ausgesetzt. Der Backup-Vorgang auf einer Single-AZ-DB-Instance führt zu einer kurzen I/O-Aussetzung, die von einigen Sekunden bis zu einigen Minuten dauern kann. Die Zeit hängt von der Größe und Klasse Ihrer DB-Instance ab.
• Bei Multi-AZ-Bereitstellungen wird die Betriebssystemwartung zuerst auf die sekundäre Instance angewendet. Die sekundäre Instance wird zur primären Instance befördert, und dann wird die Wartung an der alten primären Instance durchgeführt, die zum neuen Standby wird. Daher ist die Ausfallzeit bei bestimmten Betriebssystem-Patches in einer Multi-AZ-Instance minimal.
• Wenn Sie Ihre Multi-AZ-Instance skalieren, dann sind die Ausfallzeiten minimal. Das liegt daran, dass die sekundäre Instance zuerst geändert wird. Die sekundäre Instance wird zur primären Instance hochgestuft. Dann wird die alte primäre, jetzt sekundäre Instance geändert. Eine Single-AZ-Instance ist während des Skalierungsvorgangs nicht verfügbar.

---

Ähnliche Informationen

Multi-AZ-Bereitstellungen von Amazon RDS