Verwendung von Zero-Downtime-Patching (Patchen ohne Ausfallzeiten) - Amazon Aurora

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.

Verwendung von Zero-Downtime-Patching (Patchen ohne Ausfallzeiten)

Das Durchführen von Upgrades für Aurora MySQL DB-Cluster beinhaltet die Möglichkeit eines Ausfalls, wenn die Datenbank heruntergefahren wird und während sie aktualisiert wird. Wenn Sie das Upgrade starten, während die Datenbank ausgelastet ist, verlieren Sie standardmäßig alle Verbindungen und Transaktionen, die der DB-Cluster verarbeitet. Wenn Sie warten, bis die Datenbank im Leerlauf ist, um das Upgrade durchzuführen, müssen Sie möglicherweise lange warten.

Beim Feature des Patchens ohne Ausfallzeiten (ZDP – Zero-Downtime Patching) wird versucht, Client-Verbindungen auf Best-Effort-Basis vor der Aurora MySQL-Aktualisierung zu bewahren. Wenn das ZDP erfolgreich abgeschlossen wird, werden Anwendungssitzungen bewahrt und die Datenbank-Engine wird während der laufenden Aktualisierung neu gestartet. Der Neustart der Datenbank-Engine kann zu einem Abfall des Durchsatzes von eingen Sekunden bis 1 Minute führen.

ZDP gilt nicht für Folgendes:

  • Patches und Upgrades für das Betriebssystem

  • Hauptversions-Upgrades

ZDP ist für alle unterstützten Aurora-MySQL-Versionen und DB-Instance-Klassen verfügbar.

ZDP wird für Aurora Serverless v1- oder globale Aurora-Datenbanken nicht unterstützt.

Anmerkung

Wir empfehlen, die T-DB-Instance-Klassen nur für Entwicklungs- und Testserver oder andere Nicht-Produktionsserver zu verwenden. Weitere Einzelheiten zu den T-Instance-Klassen finden Sie unter Verwendung von T-Instance-Klassen für Entwicklung und Tests.

Sie können Metriken wichtiger Attribute während des ZDP im MySQL-Fehlerprotokoll sehen. Sie können auch Informationen darüber sehen, wann Aurora MySQL ZDP verwendet oder nicht verwendet und zwar auf der Seite Ereignisse der AWS-Managementkonsole.

In Aurora MySQL kann Aurora einen Patch ohne Ausfallzeit ausführen, unabhängig davon, ob die binäre Protokollreplikation aktiviert ist. Wenn die binäre Protokollreplikation aktiviert ist, löscht Aurora MySQL während eines ZDP-Vorgangs automatisch die Verbindung zum Binärprotokollziel. Aurora MySQL stellt automatisch eine Verbindung zum binlog-Ziel her und setzt die Replikation fort, nachdem der Neustart abgeschlossen ist.

Das ZDP arbeitet auch in Kombination mit den Neustartverbesserungen in Aurora MySQL. Durch das Patchen der Writer-DB-Instance werden die Leser automatisch gleichzeitig gepatcht. Aurora stellt nach dem Ausführen des Patches die Verbindungen sowohl auf den Writer- als auch der Reader-DB-Instances wieder

ZDP kann unter den folgenden Bedingungen möglicherweise nicht erfolgreich abgeschlossen werden:

  • Wenn langandauernde Abfragen oder Transaktionen ausgeführt werden. Wenn Aurora in diesem Fall ZDP durchführen kann, werden alle offenen Transaktionen abgebrochen, aber ihre Verbindungen beibehalten.

  • Es werden temporäre Tabellen, Benutzer- oder Tabellensperren verwendet, beispielsweise während Anweisungen für die Datendefinitionssprache (DDL) ausgeführt werden. Aurora trennt diese Verbindungen.

  • Wenn ausstehende Parameteränderungen vorhanden sind.

Wenn sich kein passendes Zeitfenster für die Durchführung von ZDP finden lässt, weil eine dieser Bedingungen vorliegt, wird das Patchen im normalen Modus ausgeführt.

Obwohl Verbindungen nach einem erfolgreichen ZDP-Vorgang intakt bleiben, werden einige Variablen und Funktionen neu initialisiert. Die folgenden Arten von Informationen werden durch einen Neustart, der durch Patchen ohne Ausfallzeiten verursacht wird, nicht beibehalten:

  • Globale Variablen Aurora stellt Sitzungsvariablen wieder her, stellt jedoch nach dem Neustart keine globalen Variablen wieder her.

  • Statusvariablen. Insbesondere wird der vom Engine-Status gemeldete Betriebszeit-Wert nach einem Neustart zurückgesetzt, der die ZDR- oder ZDP-Mechanismen verwendet.

  • LAST_INSERT_ID.

  • In-Memory-auto_increment-Status für Tabellen. Der Status des automatischen In-Memory-Inkrements wird neu initialisiert. Weitere Informationen zu automatischen Inkrementwerten finden Sie im MySQL-Referenzhandbuch.

  • Diagnoseinformationen aus INFORMATION_SCHEMA- und PERFORMANCE_SCHEMA-Tabellen. Diese Diagnoseinformationen erscheinen auch in der Ausgabe von Befehlen wie SHOW PROFILE und SHOW PROFILES.

Die folgenden Aktivitäten im Zusammenhang mit einem Neustart ohne Ausfallzeiten werden auf der Seite Ereignisse gemeldet:

  • Es wird versucht, die Datenbank ohne Ausfallzeiten zu aktualisieren.

  • Der Versuch, die Datenbank ohne Ausfallzeiten zu aktualisieren, ist beendet. Die Veranstaltung berichtet, wie lange der Prozess gedauert hat. Das Ereignis meldet auch, wie viele Verbindungen während des Neustarts beibehalten wurden und wie viele Verbindungen gelöscht wurden. Sie können das Datenbankfehlerprotokoll einsehen, um weitere Details darüber zu erfahren, was während des Neustarts passiert ist.