Fehlerbehebung für Aurora My SQL In-Place-Upgrade - 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.

Fehlerbehebung für Aurora My SQL In-Place-Upgrade

Verwenden Sie die folgenden Tipps, um Probleme mit Aurora My SQL In-Place-Upgrades zu beheben. Diese Tipps gelten nicht für Aurora Serverless DB-Cluster.

Grund für das abgebrochene oder langsame direkte Upgrade Auswirkung Lösung, die den Abschluss eines direkten Upgrades im Wartungsfenster ermöglicht
Das zugehörige regionsübergreifende Aurora-Replikat wurde noch nicht gepatcht Aurora bricht das Upgrade ab. Aktualisieren Sie das Aurora Cross-Region-Replikat und versuchen Sie es erneut.
Der Cluster hat XA-Transaktionen im vorbereiteten Zustand Aurora bricht das Upgrade ab. Bestätigen Sie alle vorbereiteten XA-Transaktionen oder setzen Sie sie zurück.
Der Cluster verarbeitet alle Anweisungen in der Datendefinitionssprache () DDL Aurora bricht das Upgrade ab. Erwägen Sie, zu warten und das Upgrade durchzuführen, nachdem alle DDL Anweisungen abgeschlossen sind.
Der Cluster hat für viele Zeilen nicht festgeschriebene Änderungen Das Upgrade könnte eine lange Zeit dauern.

Der Upgrade-Prozess setzt die nicht festgeschriebenen Änderungen zurück. Der Indikator für diese Bedingung ist der Wert von TRX_ROWS_MODIFIED in der INFORMATION_SCHEMA.INNODB_TRX-Tabelle.

Erwägen Sie, das Upgrade erst durchzuführen, nachdem alle großen Transaktionen festgeschrieben oder zurückgesetzt wurden.
Der Cluster hat eine hohe Anzahl von Undo-Datensätzen Das Upgrade könnte eine lange Zeit dauern.

Selbst wenn sich die nicht festgeschrieben Transaktionen nicht auf eine große Anzahl von Zeilen auswirken, können sie eine große Datenmenge beinhalten. Beispielsweise könnten Sie eine große BLOBs Zahl einfügen. Aurora erkennt oder generiert ein Ereignis für diese Art von Transaktionsaktivität nicht automatisch. Der Indikator für diese Bedingung ist die Länge der Verlaufsliste (HLL). Der Upgrade-Prozess setzt die nicht festgeschriebenen Änderungen zurück.

Sie können das HLL in der Ausgabe des SHOW ENGINE INNODB STATUS SQL Befehls oder direkt mit der folgenden SQL Abfrage überprüfen:

SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

Sie können die RollbackSegmentHistoryListLength Metrik auch in Amazon überwachen CloudWatch.

Erwägen Sie, das Upgrade erst durchzuführen, wenn der kleiner HLL ist.
Der Cluster ist dabei, eine große binäre Protokoll-Transaktion festzuschreiben Das Upgrade könnte eine lange Zeit dauern.

Der Upgrade-Prozess wartet, bis die binären Protokolländerungen angewendet werden. In diesem Zeitraum könnten mehr Transaktionen oder DDL Kontoauszüge beginnen, was den Upgrade-Prozess weiter verlangsamt.

Planen Sie den Upgrade-Prozess, wenn der Cluster nicht mit der Generierung von Änderungen der binären Protokollreplikation beschäftigt Aurora erkennt oder generiert ein Ereignis für diese Bedingung nicht automatisch.
Schemainkonsistenzen, die auf das Entfernen oder die Beschädigung von Dateien zurückzuführen sind Aurora bricht das Upgrade ab.

Ändern Sie die Standardspeicher-Engine für temporäre Tabellen von My ISAM auf InnoDB. Führen Sie die folgenden Schritte aus:

  1. Ändern Sie den DB-Parameter default_tmp_storage_engine in InnoDB.

  2. Starten Sie den DB-Cluster neu.

  3. Vergewissern Sie sich nach dem Neustart, dass der DB-Parameter default_tmp_storage_engine auf InnoDB festgelegt ist. Verwenden Sie den folgenden Befehl:

    show global variables like 'default_tmp_storage_engine';

  4. Achten Sie darauf, keine temporären Tabellen zu erstellen, die die ISAM Speicher-Engine My verwenden. Wir empfehlen, dass Sie jeden Datenbank-Workload unterbrechen und keine neuen Datenbankverbindungen herstellen, da Sie bald ein Upgrade durchführen werden.

  5. Versuchen Sie erneut, das direkte Upgrade durchzuführen.
Der Hauptbenutzer wurde gelöscht Aurora bricht das Upgrade ab.
Wichtig

Löschen Sie den Masterbenutzer nicht.

Sollten Sie jedoch aus irgendeinem Grund den Masterbenutzer löschen, stellen Sie ihn mithilfe der folgenden SQL Befehle wieder her:

CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, 
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, 
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;

Weitere Informationen zur Behebung von Problemen, die dazu führen, dass Upgrade-Vorabprüfungen fehlschlagen, finden Sie in den folgenden Blogs:

Sie können die folgenden Schritte verwenden, um eigene Überprüfungen für einige der Bedingungen in der vorherigen Tabelle durchzuführen. Auf diese Weise können Sie das Upgrade für einen Zeitpunkt planen, an dem Sie wissen, dass sich die Datenbank in einem Zustand befindet, in dem das Upgrade erfolgreich und schnell abgeschlossen werden kann.

  • Sie können nach offenen XA-Transaktionen suchen, indem Sie die XA RECOVER-Anweisung ausführen. Sie können dann die XA-Transaktionen festschreiben oder zurücksetzen, bevor Sie mit dem Upgrade beginnen.

  • Sie können nach DDL Anweisungen suchen, indem Sie eine SHOW PROCESSLIST Anweisung ausführen und in der Ausgabe nach CREATE DROPALTER,RENAME,, und TRUNCATE -Anweisungen suchen. Warten Sie, bis alle DDL Anweisungen abgeschlossen sind, bevor Sie das Upgrade starten.

  • Sie können die Gesamtzahl der nicht festgeschriebenen Zeilen überprüfen, indem Sie die INFORMATION_SCHEMA.INNODB_TRX-Tabelle abfragen. Die Tabelle enthält eine Zeile für jede Transaktion. Die TRX_ROWS_MODIFIED Spalte enthält die Anzahl der Zeilen, die von der Transaktion geändert oder eingefügt wurden.

  • Sie können die Länge der InnoDB-Verlaufsliste überprüfen, indem Sie die SHOW ENGINE INNODB STATUS SQL-Anweisung ausführen und nach History list length in der Ausgabe suchen. Sie können den Wert auch direkt überprüfen, indem Sie die folgende Abfrage ausführen: 

    SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

    Die Länge der Verlaufsliste entspricht der Menge der Undo-Informationen, die von der Datenbank gespeichert wurden, um die Parallelitätssteuerung mehrerer Versionen () MVCC zu implementieren.