Aktualisieren der Hauptversion eines DB-Clusters von Amazon Aurora MySQL - Amazon Aurora
Upgrade von Aurora MySQL Version 2 auf Version 3Aurora MySQL Upgrade-Vorgang für die HauptversionFunktionsweise des Aurora MySQL direkten Upgrade der HauptversionPlanen eines Hauptversionsupgrades für einen Aurora MySQL-Cluster

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.

Aktualisieren der Hauptversion eines DB-Clusters von Amazon Aurora MySQL

In einer Aurora MySQL-Versionsnummer wie 3.04.1 steht die 3 für die Hauptversion. Aurora-MySQL-Version 2 ist mit MySQL 5.7 kompatibel. Aurora-MySQL-Version 3 ist mit MySQL 8.0 kompatibel.

Das Upgrade zwischen Hauptversionen erfordert umfangreichere Planung und Tests als für eine Nebenversion. Der Prozess kann beträchtliche Zeit in Anspruch nehmen. Nachdem das Upgrade abgeschlossen ist, müssen Sie möglicherweise auch Follow-up-Arbeiten ausführen. Dies kann beispielsweise aufgrund von Unterschieden in der SQL-Kompatibilität oder der Funktionsweise bestimmter Funktionen im Zusammenhang mit MySQL nötig sein. Oder es kann aufgrund unterschiedlicher Parametereinstellungen zwischen der alten und der neuen Version erforderlich sein.

Inhalt

Upgrade von Aurora MySQL Version 2 auf Version 3

Wenn Sie einen mit MySQL 5.7 kompatiblen Cluster auf einen mit MySQL 8.0 kompatiblen Cluster aktualisieren möchten, führen Sie einen Upgrade-Prozess auf dem Cluster selbst aus. Diese Art von Upgrade ist ein direktes Upgrade im Gegensatz zu Upgrades, die Sie durch die Erstellung eines neuen Clusters durchführen. Diese Technik behält den gleichen Endpunkt und andere Eigenschaften des Clusters bei. Das Upgrade ist relativ schnell, da nicht alle Ihre Daten auf ein neues Cluster-Volume kopiert werden müssen. Diese Stabilität hilft, Konfigurationsänderungen in Ihren Anwendungen zu minimieren. Sie trägt auch dazu bei, die Anzahl der Tests für den aktualisierten Cluster zu reduzieren. Das liegt daran, dass die Anzahl der DB-Instances und ihrer Instance-Klassen gleich bleibt.

Der direkte Upgrade-Mechanismus umfasst das Herunterfahren Ihres DB-Clusters, während der Vorgang ausgeführt wird. Aurora führt ein sauberes Herunterfahren durch und schließt ausstehende Vorgänge wie Transaktions-Rollback und Rückgängig-Bereinigung ab. Weitere Informationen finden Sie unter Funktionsweise des Aurora MySQL direkten Upgrade der Hauptversion.

Die direkte Upgrade-Methode ist praktisch, da sie einfach durchzuführen ist und Konfigurationsänderungen an zugehörigen Anwendungen minimiert. Beispielsweise behält ein direktes Upgrade die Endpunkte und die Gruppe von DB-Instances für Ihren Cluster bei. Die für ein direktes Upgrade benötigte Zeit kann jedoch je nach den Eigenschaften Ihres Schemas und der Auslastung des Clusters variieren. Je nach den Anforderungen Ihres Clusters können Sie also zwischen den folgenden Upgrade-Techniken wählen:

Allgemeine Informationen zu Aurora-MySQL-Version 3 und den neuen Funktionen finden Sie unter Aurora My SQL Version 3 kompatibel mit My SQL 8.0.

Einzelheiten zur Planung eines Upgrades finden Sie unter Planen eines Hauptversionsupgrades für einen Aurora MySQL-Cluster und Erläuterung der Durchführung eines direkten Upgrades.

Aurora MySQL Upgrade-Vorgang für die Hauptversion

Nicht alle Arten oder Versionen von Aurora MySQL Clustern können den integrierten Upgrade-Mechanismus verwenden. Sie können den geeigneten Upgrade-Pfad für jeden Aurora MySQL-Cluster finden, indem Sie die folgende Tabelle konsultieren.

Typ des Aurora MySQL-DB-Clusters Kann ein direktes Upgrade verwendet werden? Aktion

Bereitgestellter Aurora MySQL-Cluster, Version 2

Ja

Das direkte Upgrade wird für MySQL 5.7-kompatible Aurora MySQL-Cluster unterstützt.

Informationen zum Upgrade auf Aurora-MySQL-Version 3 finden Sie unter Planen eines Hauptversionsupgrades für einen Aurora MySQL-Cluster und Erläuterung der Durchführung eines direkten Upgrades.

Bereitgestellter Aurora MySQL-Cluster, Version 3

Nicht zutreffend

Verwenden Sie ein Upgrade-Verfahren für Nebenversionen, um ein Upgrade zwischen Versionen von Aurora-MySQL-Version 3 durchzuführen.

Aurora Serverless v1 Cluster

Nicht zutreffend

Aurora Serverless v1 wird für Aurora MySQL nur in Version 2 unterstützt.

Aurora Serverless v2 Cluster

Nicht zutreffend

 Aurora Serverless v2 wird für Aurora MySQL nur in Version 3 unterstützt.

Cluster in einer Aurora globalen Datenbank

Ja

Wenn Sie Aurora-MySQL-Version 2 zu Version 3 aktualisieren möchten, folgen Sie den Anweisungen für ein direktes Upgrade für Cluster in einer globalen Aurora-Datenbank. Führen Sie das Upgrade auf dem globalen Cluster durch. Aurora aktualisiert den primären Cluster und alle sekundären Cluster in der globalen Datenbank gleichzeitig.

Wenn Sie die AWS CLI oder RDS-API verwenden, rufen Sie den modify-global-cluster Befehl oder die ModifyGlobalCluster Operation anstelle von modify-db-cluster oder aufModifyDBCluster.

Sie können ein direktes Upgrade von Aurora MySQL Version 2 auf Version 3 nur durchführen, wenn der lower_case_table_names Parameter auf Standard gesetzt ist und Sie Ihre globale Datenbank neu starten. Weitere Informationen finden Sie unter Hauptversions-Upgrades.

Paralleler Abfrage-Cluster

Ja

Sie können ein direktes Upgrade durchführen.

Cluster, der das Ziel der binären Protokollreplikation ist

Vielleicht

Wenn die binäre Protokollreplikation von einem Aurora-MySQL-Cluster stammt, können Sie ein direktes Upgrade durchführen. Sie können das Upgrade nicht durchführen, wenn die binäre Protokollreplikation von einer RDS-for-MySQL- oder einer On-Premises MySQL-DB-Instance stammt. In diesem Fall können Sie ein Upgrade mit dem Snapshot-Wiederherstellungsmechanismus durchführen.

Cluster mit Null DB-Instances

Nein

Mit der AWS CLI oder der RDS-API können Sie einen Aurora MySQL-Cluster ohne angehängte DB-Instances erstellen. Auf die gleiche Weise können Sie auch alle DB-Instances aus einem Aurora MySQL-Cluster entfernen, während die Daten im Cluster-Volume intakt bleiben. Während ein Cluster keine DB-Instances hat, können Sie kein direktes Upgrade durchführen.

Der Upgrade-Mechanismus erfordert eine Writer-Instance im Cluster, um Conversions für die Systemtabellen, Datendateien usw. durchzuführen. Verwenden Sie in diesem Fall die AWS CLI oder die RDS-API, um eine Writer-Instance für den Cluster zu erstellen. Dann können Sie ein direktes Upgrade durchführen.

Cluster mit aktivierter Rückverfolgung

Ja

Sie können ein direktes Upgrade für einen Aurora MySQL-Cluster durchführen, der die Backtrack-Funktion verwendet. Nach dem Upgrade können Sie den Cluster jedoch nicht auf einen Zeitpunkt vor dem Upgrade zurückverfolgen.

Funktionsweise des Aurora MySQL direkten Upgrade der Hauptversion

Aurora MySQL führt das Upgrade einer Hauptversion als mehrstufigen Prozess durch. Sie können den aktuellen Status eines Upgrades überprüfen. Einige der Upgrade-Schritte enthalten auch Fortschrittsinformationen. Beim Start jeder Phase, zeichnet Aurora MySQL ein Ereignis auf. Sie können Ereignisse so untersuchen, wenn sie auf der Seite Ereignisse in der RDS-Konsole auftreten. Weitere Informationen zur Arbeit mit -Ereignissen finden Sie unter Mit RDS Amazon-Event-Benachrichtigungen arbeiten.

Wichtig

Sobald der Prozess beginnt, wird er ausgeführt, bis das Upgrade erfolgreich ist oder fehlschlägt. Sie können das Upgrade nicht abbrechen, während es läuft. Wenn das Upgrade fehlschlägt, setzt Aurora alle Änderungen zurück und Ihr Cluster hat die gleiche Engine-Version, Metadaten usw. wie zuvor.

Der Upgrade-Prozess besteht aus drei Schritten:

  1. Aurora führt vor Beginn des Upgrade-Vorgangs eine Reihe von Vorprüfungen durch. Ihr Cluster läuft weiter, während Aurora diese Prüfungen durchführt. Zum Beispiel kann der Cluster keine XA-Transaktionen im vorbereiteten Zustand haben oder irgendwelche DDL-Anweisungen (Data Definition Language) verarbeiten. Beispielsweise müssen Sie möglicherweise Anwendungen herunterfahren, die bestimmte Arten von SQL-Anweisungen einreichen. Oder Sie könnten einfach warten, bis bestimmte lang andauernde Anweisungen beendet sind. Versuchen Sie dann erneut das Upgrade durchzuführen. Einige Prüfungen testen auf Bedingungen, die das Upgrade nicht verhindern, aber dazu führen können, dass das Upgrade möglicherweise länger dauert.

    Wenn Aurora feststellt, dass die erforderlichen Bedingungen nicht erfüllt sind, ändern Sie die in den Ereignisdetails angegebenen Bedingungen. Befolgen Sie die Anweisungen unter Fehlerbehebung für Aurora My SQL In-Place-Upgrade. Wenn Aurora Bedingungen erkennt, die ein langsames Upgrade verursachen könnten, planen Sie ein, das Upgrade über einen längeren Zeitraum zu überwachen.

  2. Aurora nimmt Ihren Cluster offline. Aurora führt dann ähnliche Tests wie in der vorherigen Phase durch, um zu bestätigen, dass während des Shutdown-Vorgangs keine neuen Probleme aufgetreten sind. Wenn Aurora zu diesem Zeitpunkt Bedingungen erkennt, die das Upgrade verhindern würden, bricht Aurora das Upgrade ab und bringt den Cluster wieder online. Bestätigen Sie in diesem Fall, wenn die Bedingungen nicht mehr gelten, und starten Sie das Upgrade erneut.

  3. Aurora erstellt einen Snapshot Ihres Cluster-Volumes. Stellen Sie sich vor, Sie stellen nach Abschluss des Upgrades Kompatibilitäts- oder andere Probleme fest. Oder angenommen, Sie möchten Tests sowohl mit den ursprünglichen als auch mit den aktualisierten Clustern durchführen. In solchen Fällen können Sie aus diesem Snapshot den Cluster wiederherstellen, um einen neuen Cluster mit der ursprünglichen Engine-Version und den ursprünglichen Daten zu erstellen.

    Tipp

    Dieser Snapshot ist ein manueller Snapshot. Aurora kann den Snapshot jedoch erstellen und den Upgrade-Prozess fortsetzen, auch wenn Sie Ihr Limit für manuelle Snapshots erreicht haben. Dieser Snapshot bleibt dauerhaft (falls erforderlich) erhalten, bis Sie ihn löschen. Nachdem Sie alle Tests nach dem Upgrade abgeschlossen haben, können Sie diesen Snapshot löschen, um die Speicherkosten zu minimieren.

  4. Aurora klont Ihr Cluster-Volume. Das Klonen ist ein schneller Vorgang, bei dem die tatsächlichen Tabellendaten nicht kopiert werden müssen. Wenn Aurora während des Upgrades ein Problem feststellt, werden die Originaldaten des geklonten Cluster-Volumes zurückgesetzt und der Cluster wieder online gebracht. Das temporär geklonte Volume während des Upgrades unterliegt nicht dem üblichen Limit für die Anzahl der Klone für ein einzelnes Cluster-Volume.

  5. Aurora führt ein sauberes Herunterfahren für die Writer-DB-Instance durch. Während des sauberen Herunterfahrens werden Fortschrittsereignisse alle 15 Minuten für die folgenden Vorgänge aufgezeichnet. Sie können Ereignisse so untersuchen, wenn sie auf der Seite Ereignisse in der RDS-Konsole auftreten.

    • Aurora bereinigt die Undo-Datensätze für alte Versionen von Zeilen.

    • Aurora setzt alle nicht festgeschriebenen Transaktionen zurück.

  6. Aurora aktualisiert die Engine-Version auf der Writer-DB-Instance:

    • Aurora installiert die Binärdatei für die neue Engine-Version auf der Writer-DB-Instance.

    • Aurora verwendet die Writer-DB-Instance, um Ihre Daten auf das mit MySQL 5.7-kompatible Format zu aktualisieren. In dieser Phase ändert Aurora die Systemtabellen und führt andere Konvertierungen durch, die sich auf die Daten in Ihrem Cluster-Volume auswirken. Insbesondere Aurora aktualisiert die Partitions-Metadaten in den Systemtabellen, um mit dem Partitionsformat MySQL 5.7 kompatibel zu sein. Diese Phase kann lange dauern, wenn die Tabellen in Ihrem Cluster eine große Anzahl von Partitionen haben.

      Wenn während dieser Phase Fehler auftreten, finden Sie die Details in den MySQL-Fehlerprotokollen. Wenn diese Phase nach dem Start der Upgradevorgang aus irgendeinem Grund fehlschlägt, stellt Aurora die Originaldaten aus dem geklonten Cluster-Volume wieder her.

  7. Aurora aktualisiert die Engine-Version auf den Reader-DB-Instances.

  8. Der Upgrade-Vorgang ist abgeschlossen. Aurora zeichnet ein letztes Ereignis auf, um anzuzeigen, dass der Upgrade-Prozess erfolgreich abgeschlossen wurde. Jetzt läuft Ihr DB-Cluster mit der neuen Hauptversion.

Planen eines Hauptversionsupgrades für einen Aurora MySQL-Cluster

Um Ihnen bei der Entscheidung über den richtigen Zeitpunkt und die richtige Vorgehensweise für ein Upgrade zu helfen, können Sie sich mit den Unterschieden zwischen Aurora MySQL Version 3 und Ihrer aktuellen Umgebung vertraut machen:

Weitere MySQL-Spezifische Upgrades und Tipps finden Sie auch unterÄnderungen in MySQL 8.0imMySQL-Referenzhandbuchaus. Sie können beispielsweise den Befehl mysqlcheck --check-upgrade verwenden, um Ihre bestehenden Aurora-MySQL-Datenbanken zu analysieren und potenzielle Upgrade-Probleme zu identifizieren.

Anmerkung

Wir empfehlen die Verwendung größerer DB-Instance-Klassen beim Upgrade auf Aurora-MySQL-Version 3 mit dem direkten Upgrade oder der Snapshot-Wiederherstellungsmethode. Beispiele sind db.r5.24xlarge und db.r6g.16xlarge. Dadurch kann der Upgrade-Prozess schneller abgeschlossen werden, da der Großteil der verfügbaren CPU-Kapazität auf der DB-Instance genutzt wird. Sie können zu der gewünschten DB-Instance-Klasse wechseln, nachdem das Upgrade der Hauptversion abgeschlossen ist.

Nachdem Sie das Upgrade selbst abgeschlossen haben, können Sie die Verfahren nach dem Upgrade unter Säuberung nach dem Upgrade für Aurora My SQL Version 3 befolgen. Testen Sie abschließend die Funktionalität und Leistung Ihrer Anwendung.

Wenn Sie von RDS aus MySQL oder Community-MySQL konvertieren, folgen Sie dem unter erläuterten MigrationsverfahrenMigrieren von Daten zu einem Amazon Aurora My SQL DB-Cluster. In einigen Fällen können Sie die Binärprotokollreplikation verwenden, um Ihre Daten im Rahmen der Migration mit einem Aurora MySQL-Cluster der Version 3 zu synchronisieren. In diesem Fall muss auf dem Quellsystem eine Version ausgeführt werden, die mit Ihrem Ziel-DB-Cluster kompatibel ist.

Damit sichergestellt wird, dass Ihre Anwendungen und Verwaltungsverfahren nach dem Upgrade eines Clusters zwischen Hauptversionen reibungslos funktionieren, führen Sie einige Vorausplanungen und Vorbereitungen durch. Informationen darüber, welche Arten von Verwaltungscode für Ihre AWS CLI Skripts oder auf der RDS-API basierenden Anwendungen aktualisiert werden müssen, finden Sie unter. Wie sich direkte Upgrades auf die Parametergruppen für einen Cluster auswirken Lesen Sie auch Änderungen an Cluster-Eigenschaften zwischen Aurora-MySQL-Versionen.

Informationen zu den Problemen, die während des Upgrades auftreten können, finden Sie unter. Fehlerbehebung für Aurora My SQL In-Place-Upgrade Bei Problemen, die dazu führen können, dass das Upgrade sehr lange dauert, können Sie diese Bedingungen im Voraus testen und korrigieren.

Anmerkung

Bei einem direkten Upgrade muss Ihr DB-Cluster heruntergefahren werden, während der Vorgang stattfindet. Aurora MySQL führt einen sauberen Shutdown durch und schließt ausstehende Operationen wie das Löschen rückgängig machen ab. Ein Upgrade kann lange dauern, wenn viele Undo-Datensätze gelöscht werden müssen. Wir empfehlen, das Upgrade erst durchzuführen, wenn die Länge der Verlaufsliste (HLL) niedrig ist. Ein allgemein akzeptabler Wert für die HLL ist 100.000 oder weniger. Weitere Informationen finden Sie in diesem Blogbeitrag.

Simulieren Sie das Upgrade, indem Sie Ihren DB-Cluster klonen

Sie können die Anwendungskompatibilität, die Leistung, die Wartungsverfahren und ähnliche Überlegungen für den aktualisierten Cluster überprüfen. Zu diesem Zweck können Sie vor dem eigentlichen Upgrade eine Simulation des Upgrades durchführen. Diese Technik kann besonders für Produktionscluster nützlich sein. Hier ist es wichtig, Ausfallzeiten zu minimieren und den aktualisierten Cluster einsatzbereit zu haben, sobald das Upgrade abgeschlossen ist.

Gehen Sie dazu wie folgt vor:

  1. Erstellen Sie einen Klon des ursprünglichen Clusters. Folgen Sie dem Verfahren unter Klonen eines Volumes für einen Amazon-Aurora-DB-Cluster.

  2. Richten Sie einen ähnlichen Satz von Writer- und Reader-DB-Instances wie im ursprünglichen Cluster ein.

  3. Führen Sie ein direktes Upgrade des geklonten Clusters durch. Folgen Sie dem Verfahren unter Erläuterung der Durchführung eines direkten Upgrades.

    Starten Sie das Upgrade sofort nach dem Erstellen des Klons. Auf diese Weise ist das Cluster-Volume immer noch identisch mit dem Zustand des ursprünglichen Clusters. Wenn der Klon vor dem Upgrade im Leerlauf ist, führt Aurora Datenbankbereinigungsprozesse im Hintergrund durch. In diesem Fall ist das Upgrade des Klons keine genaue Simulation für das Upgrade des ursprünglichen Clusters.

  4. Sie können die Anwendungskompatibilität, Performance, Administrationsprozeduren usw. mit dem geklonten Cluster testen.

  5. Wenn Probleme auftreten, passen Sie Ihre Upgrade-Pläne an, um sie zu beheben. Passen Sie beispielsweise jeden Anwendungscode so an, dass er mit dem Funktionsumfang der höheren Version kompatibel ist. Sie können abschätzen, wie lange das Upgrade wahrscheinlich auf der Grundlage der Datenmenge in Ihrem Cluster dauern wird. Sie können das Upgrade auch für eine Zeit planen, in der der Cluster nicht ausgelastet ist.

  6. Nachdem Sie sich vergewissert haben, dass Ihre Anwendungen und Workload mit dem Testcluster ordnungsgemäß funktionieren, können Sie das direkte Upgrade für Ihren Produktionscluster durchführen.

  7. Minimieren Sie möglichst die Gesamtausfallzeit Ihres Clusters während des Upgrades einer Hauptversion. Stellen Sie dazu sicher, dass die Workload auf dem Cluster zum Zeitpunkt des Upgrades niedrig oder Null ist. Stellen Sie insbesondere sicher, dass beim Start des Upgrades keine länger laufenden Transaktionen durchgeführt werden.

Blau/Grün-Bereitstellungen

In einigen Situationen ist es Ihre oberste Priorität, eine sofortige Umstellung vom alten auf einen aktualisierten Cluster durchzuführen. In solchen Situationen können Sie einen mehrstufigen Prozess verwenden, bei dem der alte und der neue Cluster ausgeführt werden. side-by-side Hier replizieren Sie Daten vom alten auf den neuen Cluster, bis der neuen Cluster zur Übernahme bereit ist. Details hierzu finden Sie unter Verwenden von Aurora Blue/Green Deployments für Datenbank-Updates.