Vorabprüfungen für das Upgrade der Hauptversion von Aurora My SQL - Amazon Aurora
Vorabprüfungsprozess für Aurora My SQLÜberprüfen Sie das Protokollformat für Aurora My vorab SQLBeispiele für Precheck-Protokollausgaben für Aurora My SQLÜberprüfen Sie die Leistung von Aurora My vorab SQLZusammenfassung der Community Meine SQL Upgrade-PrechecksZusammenfassung der Aurora My SQL Upgrade-Vorabprüfungen

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 das Upgrade der Hauptversion von Aurora My SQL

Ein Upgrade SQL von My von einer Hauptversion auf eine andere, z. B. der Wechsel von My SQL 5.7 auf My SQL 8.0, beinhaltet einige wichtige architektonische Änderungen, die eine sorgfältige Planung und Vorbereitung erfordern. Im Gegensatz zu kleineren Versionsupgrades, bei denen der Schwerpunkt hauptsächlich auf der Aktualisierung der Datenbank-Engine-Software und in einigen Fällen der Systemtabellen liegt, führen größere SQL My-Upgrades häufig zu grundlegenden Änderungen an der Art und Weise, wie die Datenbank ihre Metadaten speichert und verwaltet.

Um Sie bei der Identifizierung solcher Inkompatibilitäten zu unterstützen, führt Aurora beim Upgrade von Aurora My SQL Version 2 auf Version 3 automatisch Upgrade-Kompatibilitätsprüfungen (Vorprüfungen) durch, um Objekte in Ihrem Datenbank-Cluster zu untersuchen und bekannte Inkompatibilitäten zu identifizieren, die das Upgrade blockieren können. Einzelheiten zu den Aurora My SQL Prechecks finden Sie unterReferenz für Precheck-Beschreibungen für Aurora My SQL. Die Aurora-Vorprüfungen werden zusätzlich zu denen ausgeführt, die vom Community-Hilfsprogramm My SQL Upgrade Checker ausgefü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 zur Verfügung, in dem Sie sich darüber informieren können. Anschließend können Sie das Protokoll verwenden, um Ihre Datenbank auf das Upgrade auf Version 3 vorzubereiten, indem Sie die Inkompatibilitäten beheben. Ausführliche Informationen zur Behebung von Inkompatibilitäten finden Sie unter Vorbereiten Ihrer Installation für das Upgrade in den Abschnitten Meine SQL Dokumentation und Auf My 8.0 aktualisieren? SQL Folgendes müssen Sie wissen... auf dem My SQL Server-Blog.

    Weitere Informationen zum Upgrade auf My SQL 8.0 finden Sie unter Upgrade von My SQL in der SQL Dokumentation zu My.

Die Vorabprüfungen werden ausgeführt, bevor Ihr DB-Cluster für das Upgrade der Hauptversion offline geschaltet wird. Wenn bei den Vorprüfungen eine Inkompatibilität festgestellt wird, bricht Aurora das Upgrade automatisch ab, bevor die DB-Instance gestoppt wird. Aurora generiert auch ein Ereignis für die Inkompatibilität. Weitere Informationen zu Amazon Aurora Aurora-Veranstaltungen finden Sie unterMit RDS Amazon-Event-Benachrichtigungen arbeiten.

Nach Abschluss der Vorprüfungen zeichnet Aurora detaillierte Informationen zu jeder Inkompatibilität in der upgrade-prechecks.log Datei auf. In den meisten Fällen enthält der Protokolleintrag einen Link zu „Meine SQL Dokumentation“ zur Behebung der Inkompatibilität. 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 My SQL

Inhalt

Vorabprüfungsprozess für Aurora My SQL

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

Bei direkten Upgrades werden die Vorabprüfungen auf Ihrer Writer-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 upgrade-prechecks.log Datei protokolliert und das Upgrade wird abgebrochen. Bevor Sie das Upgrade erneut versuchen, beheben Sie alle in der upgrade-prechecks.log Datei zurückgegebenen Fehler.

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

Weitere Informationen erhalten Sie unter Finden Sie die Gründe für Fehler bei der Aktualisierung der SQL Hauptversion von Aurora My und Referenz für Precheck-Beschreibungen für Aurora My SQL.

Um den Status der Vorabprüfung zu überwachen, können Sie sich die folgenden Ereignisse in Ihrem DB-Cluster ansehen.

Status vorab prüfen Ereignismeldung Aktion

Started

Upgrade-Vorbereitung läuft: Online-Upgrade-Vorabprüfungen werden gestartet.

 None

Fehlgeschlagen

Der Datenbank-Cluster befindet sich in einem Zustand, der nicht aktualisiert werden kann: Die Upgrade-Vorprü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/neuest//AuroraUserGuide.upgrading.troubleshooting.html AuroraMy SQL

Auf upgrade-prechecks.log Fehler überprüfen.

Korrigieren Sie Fehler.

Versuchen Sie das Upgrade erneut.

Erfolgreich

Upgrade-Vorbereitung läuft: Die Online-Upgrade-Vorabprüfungen wurden abgeschlossen.

Die Vorabprüfung war erfolgreich, es wurden keine Fehler zurückgegeben.

Suchen Sie upgrade-prechecks.log nach Warnungen und Hinweisen.

Weitere Informationen zum Anzeigen von Ereignissen finden Sie unterRDSAmazon-Ereignisse anzeigen.

Überprüfen Sie das Protokollformat für Aurora My vorab SQL

Nachdem die Upgrade-Kompatibilitätsprüfungen (Vorprüfungen) abgeschlossen sind, können Sie die upgrade-prechecks.log Datei überprüfen. Die Protokolldatei enthält die Ergebnisse, die betroffenen Objekte und Behebungsinformationen 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 alle festgestellten Probleme baldmöglichst.

Die Protokolldatei hat das folgende Format:

  • targetVersion— Die My SQL -kompatible Version des Aurora SQL My-Upgrades.

  • auroraServerVersion— Die Aurora SQL My-Version, auf der der Precheck ausgeführt wurde.

  • auroraTargetVersion— Die Aurora SQL My-Version, auf die Sie aktualisieren.

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

  • id— Der Name der Vorabprüfung, die gerade ausgeführt wird.

  • 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 Vorabprüfungsabfrage an:

    • OK— Die Precheck-Abfrage wurde erfolgreich ausgeführt und abgeschlossen.

    • ERROR— Die Precheck-Abfrage konnte nicht ausgeführt werden. Dies kann auf Probleme wie Ressourcenbeschränkungen, unerwartete Instanzneustarts oder die Unterbrechung der Kompatibilitätsabfrage zur Vorabprüfung 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 zu den entsprechenden SQL Unterlagen von Aurora My SQL oder My. Weitere Informationen finden Sie unter Referenz für Precheck-Beschreibungen für Aurora My SQL.

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

    • level— Der Grad der Inkompatibilität, die bei der Vorabprüfung festgestellt wurde. 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 bald, um Probleme in future 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 bald, um Probleme in future 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 es jedoch bald, um Probleme in future Versionen zu vermeiden.

  • noticeCount— Die Anzahl der erkannten Inkompatibilitätshinweise. Diese blockieren das Upgrade nicht, sondern beheben sie bald, um Probleme in future Versionen zu vermeiden.

  • Summary— Eine Zusammenfassung der Anzahl der Kompatibilitätsfehler, Warnungen und Hinweise bei der Vorabprüfung.

Beispiele für Precheck-Protokollausgaben für Aurora My SQL

Die folgenden Beispiele zeigen die Precheck-Protokollausgabe, die Sie möglicherweise sehen. Einzelheiten zu den ausgeführten Vorprüfungen finden Sie unter. Referenz für Precheck-Beschreibungen für Aurora My SQL

Vorabprüfungsstatus OK, es wurde keine Inkompatibilität festgestellt

Die Precheck-Abfrage wurde erfolgreich abgeschlossen. Es wurden keine Inkompatibilitäten festgestellt.

{
  "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 Precheck-Abfrage wurde erfolgreich abgeschlossen. Es wurde ein Fehler festgestellt.

{
  "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üfung des Status OK, Warnung erkannt

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

Hier wurde die Precheck-Abfrage erfolgreich abgeschlossen. Zwei Warnungen wurden 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"
      }
    ]
}
Status vorab prüfenERROR, es wurden keine Inkompatibilitäten gemeldet

Die Precheck-Abfrage 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 Instanz 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 FreeableMemory CloudWatch Amazon-Metrik verwenden, um den verfügbaren Speicher 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 Blue/Green-Bereitstellung verwenden. Dadurch können Vorabprüfungen und Upgrades auf dem „grünen“ DB-Cluster unabhängig von der Produktionslast ausgeführt werden, wodurch auch Systemressourcen verbraucht werden.

Weitere Informationen finden Sie unter Behebung von Problemen mit der Speichernutzung für Aurora SQL My-Datenbanken.

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

Die Kompatibilitäts-Vorprüfungen enthalten auch Informationen zu den Ausgangs- und SQL Zielversionen von Aurora My sowie eine Zusammenfassung der Fehler-, Warn- und Hinweiszahlen am Ende der Precheck-Ausgabe.

Die folgende Ausgabe zeigt beispielsweise, dass versucht wurde, ein Upgrade von Aurora My SQL 2.11.6 auf Aurora My 3.07.1 durchzuführen. SQL 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 routineSyntaxCheckKompatibilitätsproblem 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."
}

Überprüfen Sie die Leistung von Aurora My vorab SQL

Die Kompatibilitäts-Vorabprüfungen werden ausgeführt, bevor die DB-Instance für das Upgrade offline geschaltet wird, sodass sie unter normalen Umständen nicht zu Ausfallzeiten der DB-Instance während der Ausführung führen. Sie können sich jedoch auf die Arbeitslast der Anwendung auswirken, die auf der Writer-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 die folgenden 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 removedFunctionsCheckkann es je nach Anzahl der gespeicherten Objekte länger dauern und mehr Ressourcen verbrauchen.

  • 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 verwendet wird. CPU Nach dem Upgrade können Sie die Größe verkleinern.

  • Abfragen über mehrere Datenbanken information_schema 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-Wiederherstellung oder einer Blue/Green-Implementierung für Upgrades in Betracht ziehen.

  • Die Ressourcennutzung (CPUArbeitsspeicher) mit der Vorabprüfung 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 Blue/Green-Implementierung für Upgrades durchzuführen.

    Wenn die Vorprüfungen aufgrund fehlender Ressourcen fehlschlagen, können Sie dies anhand der Statusausgabe im Precheck-Protokoll 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 Community Meine SQL Upgrade-Prechecks

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

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

    Weitere Informationen finden Sie unter Funktionen, die in My SQL 8.0 entfernt wurden, in der Dokumentation „Meine“. SQL

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

    Weitere Informationen finden Sie unter Schlüsselwörter und reservierte Wörter in der SQL Dokumentation „Meine“.

  • 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 in der Dokumentation Meine Dokumentation unter Der Zeichensatz utf8mb3 (UTF3-Byte-8-Unicode-Kodierung). SQL

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

  • Es dürfen keine Attribute vom Typ display Länge ZEROFILL oder Länge vorhanden sein.

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

  • In der My SQL mysql 5.7-Systemdatenbank dürfen keine Tabellen vorhanden sein, die denselben Namen haben wie eine Tabelle, die im My SQL 8.0-Datenwörterbuch 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.

  • In Ihrer sql_mode Systemvariableneinstellung dürfen keine veralteten SQL Modi definiert sein.

  • Es dürfen keine Tabellen oder gespeicherten Prozeduren mit einzelnen Elementen ENUM oder SET Spaltenelementen mit einer Länge von mehr als 255 Zeichen vorhanden sein.

  • Es darf keine Tabellenpartitionen geben, die sich in gemeinsam genutzten InnoDB-Tablespaces befinden.

  • Die Pfade der Tablespace-Datendateien dürfen keine Zirkelverweise enthalten.

  • Es dürfen keine Abfragen und gespeicherten Programmdefinitionen vorhanden sein, die Klauseln ASC oder DESC Kennzeichner verwenden. GROUP BY

  • Es dürfen keine Systemvariablen entfernt werden, und Systemvariablen müssen die neuen Standardwerte für My SQL 8.0 verwenden.

  • Es dürfen keine Werte von Null (0) für Datum, Uhrzeit oder Zeitstempel vorhanden sein.

  • Es dürfen keine Schemainkonsistenzen vorliegen, die auf das Entfernen oder Korrumpieren 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 My SQL 5.7 ungültig sind.

Einzelheiten zu den durchgeführten Vorprüfungen finden Sie unterReferenz für Precheck-Beschreibungen für Aurora My SQL.

Weitere Informationen zum Upgrade auf My SQL 8.0 finden Sie SQL in der SQL Dokumentation zu My unter Upgrading My. Eine allgemeine Beschreibung der Änderungen in My SQL 8.0 finden Sie unter Was ist neu in My SQL 8.0 in der SQL Dokumentation zu My 8.0.

Zusammenfassung der Aurora My SQL Upgrade-Vorabprüfungen

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

  • In Ansichten, Routinen, Triggern und QUERY_CACHE Ereignissen darf keine veraltete SQL Syntax wieSQL_CACHE,, und vorkommen. SQL_NO_CACHE

  • In keiner Tabelle ohne FTS_DOC_ID Index darf eine Spalte vorhanden sein. FTS

  • Es darf keine Diskrepanz der Spaltendefinition zwischen dem InnoDB-Datenwörterbuch und der tatsächlichen Tabellendefinition geben.

  • Alle Datenbank- und Tabellennamen müssen in Kleinbuchstaben geschrieben werden, wenn der lower_case_table_names Parameter auf gesetzt ist. 1

  • Ereignisse und Trigger dürfen keinen fehlenden oder leeren Definer oder einen ungültigen Erstellungskontext haben.

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

  • DDLRecovery und Fast DDL werden in Aurora My SQL Version 3 nicht unterstützt. Datenbanken dürfen keine Artefakte enthalten, die sich auf diese Funktionen beziehen.

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

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

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

  • Die Tabelle darf keine Inkonsistenzen der InnoDB-Metadaten enthalten. mysql.host

  • In den Systemtabellen darf es keine Diskrepanz zwischen den Spaltendatentypen geben.

  • In dem prepared Bundesstaat dürfen keine XA-Transaktionen stattfinden.

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

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

  • Tabellen dürfen keine inkonsistenten Datendateipfade aufweisen.

Einzelheiten zu den durchgeführten Vorprüfungen finden Sie unter. Referenz für Precheck-Beschreibungen für Aurora My SQL