Vorabprüfungen für Hauptversions-Upgrades von Aurora MySQL - Amazon Aurora
Vorabprüfungsprozess für Aurora MySQLVorabprüfungs-Protokollformat für Aurora MySQLBeispiele für Protokollausgaben der Vorabprüfung bei Aurora MySQLLeistung der Vorabprüfung bei Aurora MySQLZusammenfassung der Vorabprüfungen für Community-MySQL-UpgradesZusammenfassung der Vorabprüfungen für Aurora-MySQL-Upgrades

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.

Vorabprüfungen für Hauptversions-Upgrades von Aurora MySQL

Ein Upgrade von MySQL von einer Hauptversion auf eine andere, wie z. B. die Umstellung von MySQL 5.7 auf MySQL 8.0, beinhaltet einige wichtige architektonische Änderungen, die eine sorgfältige Planung und Vorbereitung erfordern. Im Gegensatz zu Nebenversions-Upgrades, bei denen der Schwerpunkt hauptsächlich auf der Aktualisierung der Datenbank-Engine-Software und in einigen Fällen der Systemtabellen liegt, führen Hauptversions-Upgrades von MySQL häufig zu grundlegenden Änderungen daran, wie die Datenbank ihre Metadaten speichert und verwaltet.

Zur Unterstützung bei der Identifizierung solcher Inkompatibilitäten führt Aurora beim Upgrade von Aurora-MySQL-Version 2 auf Version 3 automatisch Upgrade-Kompatibilitätsprüfungen (Vorabprüfungen) durch. Dabei werden Objekte in Ihrem Datenbank-Cluster untersucht und bekannte Inkompatibilitäten identifiziert, die das Upgrade blockieren können. Weitere Informationen zu Aurora-MySQL-Vorabprüfungen finden Sie unter Referenz zu Vorabprüfungsbeschreibungen für Aurora MySQL. Die Aurora-Vorabprüfungen werden zusätzlich zu denen ausgeführt, die vom Upgrade-Checker-Dienstprogramm von Community MySQL durchgeführt werden.

Diese Vorabprüfungen müssen durchgeführt werden. Sie können nicht ausgelassen werden. Die Vorabprüfungen bieten folgende Vorteile:

  • Sie können die Wahrscheinlichkeit verringern, dass Upgrade-Fehler auftreten, die zu längeren Ausfallzeiten führen können.

  • Wenn es Inkompatibilitäten gibt, verhindert Amazon Aurora, dass das Upgrade fortgesetzt wird, und stellt Ihnen ein Protokoll mit Informationen zu den Inkompatibilitäten bereit. Sie können das Protokoll für die Vorbereitung Ihrer Datenbank auf das Upgrade auf Version 3 verwenden, indem Sie die Inkompatibilitäten beheben. Detaillierte Informationen zum Beheben von Inkompatibilitäten finden Sie unter Vorbereiten Ihrer Installation auf ein Upgrade in der MySQL-Dokumentation und unter Upgrade auf MySQL 8.0?. Dies müssen Sie wissen ... im MySQL Server Blog.

    Weitere Informationen zum Ausführen von Upgrades auf MySQL 8.0 finden Sie unter Ausführen von MySQL-Upgrades in der MySQL-Dokumentation.

Die Vorabprüfungen werden ausgeführt, bevor Ihr DB-Cluster für das Hauptversions-Upgrade offline geschaltet wird. Wird während der Vorabprüfungen eine Inkompatibilität entdeckt, bricht Aurora automatisch das Upgrade ab, ehe die DB-Instance angehalten wird. Aurora generiert auch ein Ereignis für die Inkompatibilität. Weitere Informationen über Amazon-Aurora-Ereignisse finden Sie unter Arbeiten mit Amazon-RDS-Ereignisbenachrichtigungen.

Nach Abschluss der Vorabprüfungen zeichnet Aurora detaillierte Informationen zu allen Inkompatibilitäten in der Datei upgrade-prechecks.log auf. In den meisten Fällen enthalten die Protokolleinträge einen Link zur MySQL-Dokumentation mit Informationen zur Lösung des Inkompatibilitätsproblems. Weitere Informationen zum Anzeigen von Protokolldateien finden Sie unter Anzeigen und Auflisten von Datenbank-Protokolldateien.

Anmerkung

Aufgrund der Art der Vorabprüfungen werden die Objekte in Ihrer Datenbank geprüft. Diese Analyse verbraucht Ressourcen und verlängert die Zeit, die für die Durchführung des Upgrades benötigt wird. Weitere Informationen zu Leistungsaspekten bei der Vorabprüfung finden Sie unter Vorabprüfungsprozess für Aurora MySQL.

Inhalt

Vorabprüfungsprozess für Aurora MySQL

Wie bereits beschrieben, beinhaltet der Upgrade-Prozess von Aurora MySQL die Durchführung von Kompatibilitätsprüfungen (Vorabprüfungen) für Ihre Datenbank, bevor das Hauptversions-Upgrade fortgesetzt werden kann.

Bei direkten Upgrades werden die Vorabprüfungen auf Ihrer Schreiber-DB-Instance ausgeführt, während diese online ist. Wenn die Vorabprüfung erfolgreich ist, wird das Upgrade fortgesetzt. Wenn Fehler gefunden werden, werden sie in der Datei upgrade-prechecks.log protokolliert und das Upgrade wird abgebrochen. Bevor Sie das Upgrade erneut versuchen, beheben Sie alle in der Datei upgrade-prechecks.log zurückgegebenen Fehler.

Bei Snapshot-Wiederherstellungs-Upgrades wird die Vorabprüfung während des Wiederherstellungsprozesses ausgeführt. Wenn diese erfolgreich ist, wird Ihre Datenbank auf die neue Aurora-MySQL-Version aktualisiert. Wenn Fehler gefunden werden, werden sie in der Datei upgrade-prechecks.log protokolliert und das Upgrade wird abgebrochen. Bevor Sie das Upgrade erneut versuchen, beheben Sie alle in der Datei upgrade-prechecks.log zurückgegebenen Fehler.

Weitere Informationen erhalten Sie unter Finden der Gründe für Fehler bei Hauptversion-Upgrades von Aurora MySQL und Referenz zu Vorabprüfungsbeschreibungen für Aurora MySQL.

Wenn Sie den Vorabprüfungsstatus überwachen möchten, können Sie die folgenden Ereignisse in Ihrem DB-Cluster anzeigen.

Vorabprüfungsstatus Ereignismeldung Aktion

Gestartet

Upgrade-Vorbereitung im Gange: Die Online-Upgrade-Vorabprüfungen werden gestartet.

 Keine

Fehlgeschlagen

Der Datenbank-Cluster befindet sich in einem Zustand, der nicht aktualisiert werden kann. Upgrade-Vorabprüfungen sind fehlgeschlagen. Weitere Informationen finden Sie in der Datei upgrade-prechecks.log.

Weitere Informationen zur Behebung der Ursache des Upgrade-Fehlers finden Sie unter

https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html

Überprüfen Sie upgrade-prechecks.log auf Fehler.

Beheben Sie die Fehler.

Versuchen Sie das Upgrade erneut.

Erfolgreich

Upgrade-Vorbereitung im Gange: Die Online-Upgrade-Vorabprüfungen wurden abgeschlossen.

Die Vorabprüfung wurde erfolgreich abgeschlossen. Es wurden keine Fehler erkannt.

Überprüfen Sie upgrade-prechecks.log auf Warnungen und Hinweise.

Weitere Informationen zum Anzeigen von Ereignissen finden Sie unter Anzeigen von Amazon-RDS-Ereignissen.

Vorabprüfungs-Protokollformat für Aurora MySQL

Nachdem die Upgrade-Kompatibilitätsprüfungen (Vorabprüfungen) abgeschlossen sind, können Sie die Datei upgrade-prechecks.log überprüfen. Die Protokolldatei enthält die Ergebnisse, die betroffenen Objekte und Informationen zur Behebung für jede Vorabprüfung.

Fehler blockieren das Upgrade. Sie müssen sie beheben, bevor Sie das Upgrade erneut versuchen können.

Warnungen und Hinweise sind weniger wichtig, aber wir empfehlen dennoch, sie sorgfältig zu überprüfen, um sicherzustellen, dass keine Kompatibilitätsprobleme mit dem Anwendungs-Workload vorliegen. Beheben Sie erkannte Probleme zeitnah.

Die Protokolldatei hat folgendes Format:

  • targetVersion – Die MySQL-kompatible Version des Aurora-MySQL-Upgrades

  • auroraServerVersion – Die Aurora-MySQL-Version, auf der die Vorabprüfung ausgeführt wurde

  • auroraTargetVersion – Die Aurora-MySQL-Version, auf die Sie aktualisieren

  • checksPerformed – Enthält die Liste der durchgeführten Vorabprüfungen

  • id – Der Name der gerade ausgeführten Vorabprüfung

  • title – Eine Beschreibung der gerade ausgeführten Vorabprüfung

  • status – Dies gibt nicht an, ob die Vorabprüfung erfolgreich war oder nicht, sondern zeigt den Status der Abfrage zur Vorabprüfung an.

    • OK – Die Abfrage zur Vorabprüfung wurde erfolgreich ausgeführt und abgeschlossen.

    • ERROR – Die Abfrage zur Vorabprüfung konnte nicht ausgeführt werden. Dies kann auf Probleme wie Ressourcenbeschränkungen, unerwartete Instance-Neustarts oder die Unterbrechung der Abfrage zur Vorabprüfung der Kompatibilität zurückzuführen sein.

      Weitere Informationen finden Sie in diesem Beispiel.

  • description – Eine allgemeine Beschreibung der Inkompatibilität und wie das Problem behoben werden kann

  • documentationLink – Gegebenenfalls finden Sie hier einen Link zur entsprechenden Aurora-MySQL- oder MySQL-Dokumentation. Weitere Informationen finden Sie unter Referenz zu Vorabprüfungsbeschreibungen für Aurora MySQL.

  • detectedProblems – Wenn bei der Vorabprüfung ein Fehler, eine Warnung oder ein Hinweis zurückgegeben wird, werden hier Details zur Inkompatibilität und gegebenenfalls inkompatible Objekte angezeigt.

    • level – Die bei der Vorabprüfung festgestellte Stufe der Inkompatibilität. Folgende Stufen sind gültig:

      • Error – Das Upgrade kann erst fortgesetzt werden, wenn Sie die Inkompatibilität behoben haben

      • Warning – Das Upgrade kann fortgesetzt werden, es wurde jedoch ein veraltetes Objekt, eine veraltete Syntax oder Konfiguration erkannt. Lesen Sie die Warnungen sorgfältig und beheben Sie sie zeitnah, um Probleme in künftigen Versionen zu vermeiden.

      • Notice – Das Upgrade kann fortgesetzt werden, es wurde jedoch ein veraltetes Objekt, eine veraltete Syntax oder Konfiguration erkannt. Lesen Sie die Hinweise sorgfältig und beheben Sie sie zeitnah, um Probleme in künftigen Versionen zu vermeiden.

    • dbObject – Der Name des Datenbankobjekts, in dem die Inkompatibilität festgestellt wurde

    • description – Eine detaillierte Beschreibung der Inkompatibilität und wie das Problem behoben werden kann

  • errorCount – Die Anzahl der erkannten Inkompatibilitätsfehler. Diese blockieren das Upgrade.

  • warningCount – Die Anzahl der erkannten Inkompatibilitätswarnungen. Diese blockieren das Upgrade nicht, beheben Sie sie jedoch zeitnah, um Probleme in künftigen Versionen zu vermeiden.

  • noticeCount – Die Anzahl der erkannten Inkompatibilitätshinweise. Diese verhindern das Upgrade nicht, sollten jedoch zeitnah behoben werden, um Probleme in künftigen Versionen zu vermeiden.

  • Summary – Eine Zusammenfassung der Anzahl von Kompatibilitätsfehlern, -warnungen und -hinweisen aus der Vorabprüfung

Beispiele für Protokollausgaben der Vorabprüfung bei Aurora MySQL

Die folgenden Beispiele zeigen die Protokollausgaben der Vorabprüfung, die Sie möglicherweise angezeigt bekommen. Weitere Informationen zu den ausgeführten Vorabprüfungen finden Sie unter Referenz zu Vorabprüfungsbeschreibungen für Aurora MySQL.

Vorabprüfungsstatus OK, keine Inkompatibilität erkannt

Die Abfrage zur Vorabprüfung wurde erfolgreich abgeschlossen. Es wurden keine Inkompatibilitäten erkannt.

{
  "id": "auroraUpgradeCheckIndexLengthLimitOnTinytext",
  "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny text columns",
  "status": "OK",
  "detectedProblems": []
},
Vorabprüfungsstatus OK, Fehler erkannt

Die Abfrage zur Vorabprüfung wurde erfolgreich abgeschlossen. Es wurde ein Fehler erkannt.

{
  "id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
  "title": "Check for geometry columns on prefix indexes",
  "status": "OK",
  "description": "Consider dropping the prefix indexes of geometry columns and restart the upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test25.sbtest1",
        "description": "Table `test25`.`sbtest1` has an index `idx_t1` on geometry column/s. Mysql 8.0 does not support this type of index on a geometry column https://dev.mysql.com/worklog/task/?id=11808. To upgrade to MySQL 8.0, Run 'DROP INDEX `idx_t1` ON `test25`.`sbtest1`;"
      },
 }
Vorabprüfungsstatus OK, Warnung erkannt

Warnungen können zurückgegeben werden, wenn eine Vorabprüfung erfolgreich oder nicht erfolgreich war.

Hier wurde die Abfrage zur Vorabprüfung erfolgreich abgeschlossen. Es wurden zwei Warnungen erkannt.

{
  "id": "zeroDatesCheck",
  "title": "Zero Date, Datetime, and Timestamp values",
  "status": "OK",
  "description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.",
  "documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "global.sql_mode",
        "description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
      },
      {
        "level": "Warning",
        "dbObject": "session.sql_mode",
        "description": " of 10 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
      }
    ]
}
Vorabprüfungsstatus ERROR, keine Inkompatibilitäten gemeldet

Die Abfrage zur Vorabprüfung schlug mit einem Fehler fehl, sodass Inkompatibilitäten nicht verifiziert werden konnten.

{
  "id": "auroraUpgradeCheckForDatafilePathInconsistency",
  "title": "Check for inconsistency related to ibd file path.",
  "status": "ERROR",
  "description": "Can't connect to MySQL server on 'localhost:3306' (111) at 13/08/2024 12:22:20 UTC. This failure can occur due to low memory available on the instance for executing upgrade prechecks. Please check 'FreeableMemory' Cloudwatch metric to verify the available memory on the instance while executing prechecks. If instance ran out of memory, we recommend to retry the upgrade on a higher instance class."
}

Dieser Fehler kann auftreten, wenn die Instance unerwartet neu gestartet wurde oder eine Abfrage zur Vorabprüfung der Kompatibilität in der Datenbank während der Ausführung unterbrochen wurde. Bei kleineren DB-Instance-Klassen kann dies beispielsweise auftreten, wenn der verfügbare Speicher auf der Instance knapp wird.

Sie können die Amazon-CloudWatch-Metrik FreeableMemory verwenden, um den verfügbaren Arbeitsspeicher auf der Instance zu überprüfen, während Sie Vorabprüfungen ausführen. Wenn der Instance nicht mehr genügend Arbeitsspeicher zur Verfügung steht, empfehlen wir, das Upgrade auf einer größeren DB-Instance-Klasse erneut durchzuführen. In einigen Fällen können Sie eine Blau/Grün-Bereitstellung verwenden. Auf diese Weise können Vorabprüfungen und Upgrades im „grünen“ DB-Cluster unabhängig vom Produktions-Workload ausgeführt werden, wodurch auch Systemressourcen verbraucht werden.

Weitere Informationen finden Sie unter Beheben von Problemen mit der Speichernutzung bei Aurora-MySQL-Datenbanken.

Zusammenfassung der Vorabprüfung: Ein Fehler und drei Warnungen erkannt

Die Vorabprüfungen der Kompatibilität enthalten auch Informationen zu den Quell- und Zielversionen von Aurora MySQL sowie eine Zusammenfassung der Anzahl von Fehlern, Warnungen und Hinweisen am Ende der Ausgabe der Vorabprüfung.

Die folgende Ausgabe zeigt beispielsweise, dass versucht wurde, ein Upgrade von Aurora MySQL 2.11.6 auf Aurora MySQL 3.07.1 durchzuführen. Das Upgrade hat einen Fehler, drei Warnungen und keine Hinweise zurückgegeben. Da Upgrades nicht fortgesetzt werden können, wenn ein Fehler zurückgegeben wird, müssen Sie das Kompatibilitätsproblem routineSyntaxCheck beheben und das Upgrade erneut versuchen.

{
  "serverAddress": "/tmp%2Fmysql.sock",
  "serverVersion": "5.7.12 - MySQL Community Server (GPL)",
  "targetVersion": "8.0.36",
  "auroraServerVersion": "2.11.6",
  "auroraTargetVersion": "3.07.1",
  "outfilePath": "/rdsdbdata/tmp/PreChecker.log",
  "checksPerformed": [{
      ... output for each individual precheck ...
      .
      .
      {
        "id": "oldTemporalCheck",
        "title": "Usage of old temporal type",
        "status": "OK",
          "detectedProblems": []
      },
      {
        "id": "routinesSyntaxCheck",
        "title": "MySQL 8.0 syntax check for routine-like objects",
        "status": "OK",
        "description": "The following objects did not pass a syntax check with the latest MySQL 8.0 grammar. A common reason is that they reference names that conflict with new reserved keywords. You must update these routine definitions and `quote` any such references before upgrading.",
        "documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
        "detectedProblems": [{
            "level": "Error",
            "dbObject": "test.select_res_word",
            "description": "at line 2,18: unexpected token 'except'"
        }]
      },
      .
      .
      .
      {
        "id": "zeroDatesCheck",
        "title": "Zero Date, Datetime, and Timestamp values",
        "status": "OK",
        "description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.",
        "documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/",
        "detectedProblems": [{
            "level": "Warning",
            "dbObject": "global.sql_mode",
            "description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
            },
            {
            "level": "Warning",
            "dbObject": "session.sql_mode",
            "description": " of 8 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
            }
          ]
       },
       .
       .
       .
  }],
  "errorCount": 1,
  "warningCount": 3,
  "noticeCount": 0,
  "Summary": "1 errors were found. Please correct these issues before upgrading to avoid compatibility issues."
}

Leistung der Vorabprüfung bei Aurora MySQL

Die Vorabprüfungen der Kompatibilität erfolgen vor der Offline-Schaltung der DB-Instance für das Upgrade und führen unter normalen Umständen zu keiner Ausfallzeit. Sie können jedoch Auswirkungen auf den Anwendungs-Workload haben, der auf der Schreiber-DB-Instance ausgeführt wird. Die Vorabprüfungen greifen über information_schema-Tabellen auf das Datenwörterbuch zu, was bei vielen Datenbankobjekten langsam sein kann. Berücksichtigen Sie folgende Faktoren:

  • Die Dauer der Vorabprüfung hängt von der Anzahl der Datenbankobjekte wie Tabellen, Spalten, Routinen und Einschränkungen ab. Die Ausführung von DB-Clustern mit einer großen Anzahl von Objekten kann länger dauern.

    Beispielsweise kann der removedFunctionsCheck länger dauern und je nach Anzahl der gespeicherten Objekte mehr Ressourcen beanspruchen.

  • Bei direkten Upgrades kann die Verwendung einer größeren DB-Instance-Klasse (z. B. db.r5.24xlarge oder db.r6g.16xlarge) dazu beitragen, dass das Upgrade schneller abgeschlossen wird, da mehr CPU verwendet wird. Eine Verkleinerung ist nach dem Upgrade möglich.

  • Abfragen zum information_schema über mehrere Datenbanken hinweg können langsam sein, insbesondere bei vielen Objekten und auf kleineren DB-Instances. In solchen Fällen sollten Sie die Verwendung von Klonen, Snapshot-Wiederherstellungen oder einer Blau/Grün-Bereitstellung für Upgrades in Betracht ziehen.

  • Die Vorabprüfungs-Ressourcennutzung (CPU, Arbeitsspeicher) kann mit mehr Objekten zunehmen, was zu längeren Laufzeiten auf kleineren DB-Instances führt. In solchen Fällen sollten Sie erwägen, Tests mithilfe von Klonen, Snapshot-Wiederherstellung oder einer Blau/Grün-Bereitstellung für Upgrades durchzuführen.

    Wenn die Vorabprüfungen aufgrund fehlender Ressourcen fehlschlagen, können Sie dies anhand der Statusausgabe im Vorabprüfungsprotokoll erkennen:

    "status": "ERROR",

Weitere Informationen erhalten Sie unter Funktionsweise des Aurora MySQL direkten Upgrade der Hauptversion und Planen eines Hauptversionsupgrades für einen Aurora MySQL-Cluster.

Zusammenfassung der Vorabprüfungen für Community-MySQL-Upgrades

Im Folgenden finden Sie eine allgemeine Liste der Inkompatibilitäten zwischen MySQL 5.7 und 8.0:

  • Ihr MySQL-5.7-kompatibler DB-Cluster darf keine Funktionen verwenden, die in MySQL 8.0 nicht unterstützt werden.

    Weitere Informationen finden Sie unter In MySQL 8.0 entfernte Funktionen in der MySQL-Dokumentation.

  • Es darf keine Verletzungen von Schlüsselwörtern oder reservierten Wörtern geben. Einige Schlüsselwörter sind in MySQL 8.0 möglicherweise reserviert, die zuvor nicht reserviert waren.

    Weitere Informationen finden Sie unter Schlüsselwörter und reservierte Wörter in der MySQL-Dokumentation.

  • Um die Unicode-Unterstützung zu verbessern, sollten Sie die Konvertierung von Objekten, die den utf8mb3-Zeichensatz verwenden, in Objekte in Betracht ziehen, die den utf8mb4-Zeichensatz verwenden. Der utf8mb3-Zeichensatz ist veraltet. Sie sollten darüber hinaus anstelle von utf8mb4 die Verwendung von utf8 für Zeichensatzverweise in Betracht ziehen, da utf8 zurzeit ein Alias für den utf8mb3-Zeichensatz ist.

    Weitere Informationen finden Sie unter Der utf8mb3-Zeichensatz (UTF-8-Unicode-Kodierung mit 3 Bytes) in der MySQL-Dokumentation.

  • Es darf keine InnoDB-Tabellen mit einem nicht standardmäßigen Zeilenformat geben.

  • Es darf keine ZEROFILL- oder display-Längentyp-Attribute geben.

  • Es darf keine partitionierte Tabelle mit einer Speicher-Engine geben, für die es keine native Partitionierungsunterstützung gibt.

  • Es darf keine Tabellen in der MySQL 5.7 mysql-Systemdatenbank geben, die denselben Namen wie eine Tabelle haben, die vom MySQL 8.0-Daten-Dictionary verwendet wird.

  • Es darf keine Tabellen geben, die veraltete Datentypen oder Funktionen verwenden.

  • Es darf keine Namen für Fremdschlüsseleinschränkungen mit mehr als 64 Zeichen geben.

  • Es dürfen keine veralteten SQL-Modi in Ihrer sql_mode-Systemvariableneinstellung definiert sein.

  • Es darf keine Tabellen oder gespeicherte Prozeduren mit einzelnen ENUM- oder SET-Spaltenelementen geben, deren Länge 255 Zeichen überschreitet.

  • Es darf keine Tabellenpartitionen innerhalb von freigegebenen InnoDB-Tablespaces geben.

  • Es darf keine zirkulären Referenzen in Tablespace-Datendateipfaden geben.

  • Es darf keine Abfragen oder gespeicherten Programmdefinitionen geben, die ASC- oder DESC-Qualifizierer für GROUP BY-Klauseln verwenden.

  • Es darf keine entfernten Systemvariablen geben und Systemvariablen müssen die neuen Standardwerte für MySQL 8.0 verwenden.

  • Es darf keine Nullwerte (0) für Date, Datetime oder Timestamp geben.

  • Es darf keine Schemainkonsistenzen geben, die auf das Entfernen oder die Beschädigung von Dateien zurückzuführen sind.

  • Es darf keine Tabellennamen geben, die die FTS-Zeichenfolge enthalten.

  • Es darf keine InnoDB-Tabellen geben, die zu einer anderen Engine gehören.

  • Es darf keine Tabellen- oder Schemanamen geben, die für MySQL 5.7 ungültig sind.

Weitere Informationen zu den ausgeführten Vorabprüfungen finden Sie unter Referenz zu Vorabprüfungsbeschreibungen für Aurora MySQL.

Weitere Informationen zum Ausführen von Upgrades auf MySQL 8.0 finden Sie unter Ausführen von MySQL-Upgrades in der MySQL-Dokumentation. Eine allgemeine Beschreibung der Änderungen in MySQL 8.0 finden Sie unter Was ist neu in MySQL 8.0 in der MySQL-Dokumentation.

Zusammenfassung der Vorabprüfungen für Aurora-MySQL-Upgrades

Aurora MySQL hat beim Upgrade von Version 2 auf Version 3 seine eigenen spezifischen Anforderungen, darunter die folgenden:

  • Es darf keine veraltete SQL-Syntax wie SQL_CACHE, SQL_NO_CACHE und QUERY_CACHE in Ansichten, Routinen, Triggern und Ereignissen geben.

  • Es darf in keiner Tabelle eine FTS_DOC_ID-Spalte ohne FTS-Index geben.

  • Es darf keine Nichtübereinstimmung von Spaltendefinitionen zwischen dem InnoDB-Datenwörterbuch und der tatsächlichen Tabellendefinition geben.

  • Alle Datenbank- und Tabellennamen dürfen nur Kleinbuchstaben enthalten, wenn der Parameter lower_case_table_names auf 1 gesetzt ist.

  • Es darf keine Ereignisse und Trigger mit fehlenden oder leeren Definern oder ungültigen Erstellungskontexten geben.

  • Alle Triggernamen in einer Datenbank müssen eindeutig sein.

  • Die DDL-Wiederherstellung und schnelle DDL werden in Aurora-MySQL-Version 3 nicht unterstützt. Es darf keine Artefakte in Datenbanken geben, die mit diesen Funktionen in Zusammenhang stehen.

  • Tabellen mit dem Zeilenformat REDUNDANT oder COMPACT dürfen keine Indizes größer als 767 Byte enthalten.

  • Die Präfixlänge von Indizes, die für tiny-Textspalten definiert sind, darf 255 Byte nicht überschreiten. Mit dem utf8mb4-Zeichensatz ist die unterstützte Präfixlänge auf 63 Zeichen begrenzt.

    Eine größere Präfixlänge war in MySQL 5.7 unter Verwendung des Parameters innodb_large_prefix zulässig. Dieser Parameter ist seit MySQL 8.0 veraltet.

  • Es darf keine Inkonsistenzen der InnoDB-Metadaten in der Tabelle mysql.host geben.

  • Es darf keine Nichtübereinstimmung von Spaltendatentypen in den Systemtabellen geben.

  • Es darf keine XA-Transaktionen im prepared-Status geben.

  • Spaltennamen in Ansichten dürfen nicht länger als 64 Zeichen sein.

  • Sonderzeichen in gespeicherten Prozeduren dürfen nicht inkonsistent sein.

  • Es darf keine Inkonsistenz bei den Datendateipfaden von Tabellen geben.

Weitere Informationen zu den ausgeführten Vorabprüfungen finden Sie unter Referenz zu Vorabprüfungsbeschreibungen für Aurora MySQL.