Auf dieser Seite werden bekannte Probleme und Inkompatibilitäten beschrieben, die bei Vorprüfungen während eines Hauptversionsupgrades von Cloud SQL for MySQL 5.7 auf Cloud SQL for MySQL 8.0 auftreten können.
Weitere Informationen zum Upgrade der Hauptversion finden Sie unter Direkte Datenbankaktualisierung durchführen und Fehlerlogs ansehen.
Inkompatible SQL-Änderungen
In diesem Abschnitt werden SQL-Inkompatibilitäten in Cloud SQL 5.7 und Cloud SQL 8.0 aufgeführt, die beim Ausführen des Precheck-Tools oder während des Upgrades auftreten können. Außerdem erhalten Sie Vorschläge zum Beheben der einzelnen Fehler.
Reservierte Keywords
Der folgende Fehler tritt auf, wenn Sie versuchen, ein reserviertes Keyword zu verwenden:
Warning: The following objects have names that conflict with new reserved keywords. Ensure queries sent by your applications use `quotes` when referring to them or they will result in errors.
Dieser Fehler tritt auf, wenn Sie versuchen, Schlüsselwörter zu verwenden, die in MySQL-Version 8.0 als reserviert klassifiziert sind, z. B.:
GROUPSLEADRANK
Das bedeutet, dass einige Wörter, die zuvor als Kennungen verwendet wurden, jetzt als illegal gelten können. Um dieses Problem zu beheben, korrigieren Sie die betroffenen Anweisungen, indem Sie die Kennzeichnung in Anführungszeichen setzen oder die Kennzeichnung umbenennen.
Eine vollständige Liste der Schlüsselwörter finden Sie unter Schlüsselwörter und reservierte Wörter.
ASC/DESC-Anweisung mit GROUP BY-Klausel entfernt
Der folgende Fehler tritt auf, wenn Sie versuchen, ASC/DESC mit der Klausel GROUP BY zu verwenden:
[ERROR] [MY-013235] [Server] Error in parsing Routine db_name.routine_name during upgrade. You may have an error in your SQL syntax; check the manual that corresponding to your MySQL server version for the right syntax to use near 'some_text'
In diesem Fall kann auch die folgende Fehlermeldung angezeigt werden:
[ERROR] [MY-013235] [Server] Unknown trigger has an error in its body: 'You have an error in you SQL syntax; [ERROR] [MY-010198] [Server] Error in parsing Triggers from trigger_name.TRG file.
Dieser Fehler tritt auf, wenn Sie versuchen, Ihre Abfrage mit GROUP BY zu sortieren.
Abfragen, die zuvor auf die GROUP BY-Sortierung angewiesen waren, können Ergebnisse liefern, die sich von früheren MySQL-Versionen unterscheiden. Wenn Sie eine bestimmte Sortierreihenfolge beibehalten möchten, geben Sie eine ORDER BY-Klausel an.
Verwenden Sie die ORDER BY-Klausel, um das Problem zu beheben. Wenn beispielsweise eine gespeicherte Prozedur, ein Trigger oder eine Ereignisdefinition eine Abfrage enthält, in der ASC oder DESC mit der GROUP BY-Klausel verwendet wird, muss die Abfrage des Objekts eine ORDER BY-Klausel enthalten.
Weitere Informationen finden Sie unter Syntax für GROUP BY ASC und DESC entfernen.
Mix aus räumlichen Daten und anderen Typen als Schlüssel
Der folgende Fehler tritt auf, wenn Sie den falschen Präfixschlüssel verwenden:
[ERROR] [MY-013140] [Server] Incorrect prefix key; the used key part isn't a string, the used length is longer than the key part, or the storage engine doesn't support unique prefix keys [ERROR] [MY-013140] [Server] Too many key parts specified; max 1 parts allowed
Dieser Fehler tritt auf, wenn Sie versuchen, räumliche Daten mit anderen Typen als Schlüssel zu verwenden.
In MySQL ab Version 8.0 darf ein Index keine Mischung aus räumlichen und anderen Datentypen enthalten. Sie müssen den Schlüssel entfernen und einen neuen erstellen, der in MySQL-Version 8.0 oder höher unterstützt wird. Weitere Informationen finden Sie unter Räumliche Indexe.
Um dieses Problem zu beheben, ermitteln Sie die räumlichen Datenindexe mit einer Abfrage, die der folgenden ähnelt:
SELECT s.TABLE_SCHEMA, s.TABLE_NAME, s.INDEX_NAME, s.COLUMN_NAME, s.INDEX_TYPE, c.DATA_TYPE FROM information_schema.STATISTICS s JOIN information_schema.COLUMNS c ON s.TABLE_SCHEMA = c.TABLE_SCHEMA AND s.TABLE_NAME = c.TABLE_NAME AND s.COLUMN_NAME = c.COLUMN_NAME WHERE c.DATA_TYPE IN ( 'geometry', 'point', 'linestring', 'polygon', 'multipoint', 'multilinestring', 'multipolygon', 'geometrycollection' ) AND s.INDEX_TYPE = 'BTREE';
Ungültige UTF-8-Zeichen
Der folgende Fehler tritt auf, wenn Sie ungültige UTF8-Zeichenfolgen verwenden:
[ERROR] [MY-010765] [Server] Error in Creating DD entry for %s.%s [ERROR] [MY-013140] [Server] Invalid utf8 character string: invalid_string
Dieser Fehler tritt auf, wenn Befehle ungültige UTF8-Zeichen enthalten. Wenn eine Tabellendefinition beispielsweise ungültige UTF8-Zeichen enthält, kann die Konvertierung der Tabellendefinitionen in das Data Dictionary fehlschlagen.
Um dieses Problem zu beheben, müssen Sie die ungültigen Zeichen entweder durch die entsprechenden UTF8-Zeichen ersetzen oder ganz entfernen.
Mit einer Abfrage wie der folgenden können Sie ungültige Zeichen ermitteln und korrigieren:
SHOW CREATE TABLE table_name; ALTER TABLE table_name MODIFY COLUMN column_name data_type comment=''; // removing invalid utf8 character from comment
Nicht übergebene XA-Transaktionen
Der folgende Fehler tritt auf, wenn vorbereitete XA-Transaktionen vorhanden sind:
[ERROR] [MY-013527] [Server] Upgrade cannot proceed due to an existing prepared XA transactions
Dieser Fehler tritt auf, wenn nicht übertragene XA-Transaktionen vorhanden sind, die dazu führen, dass das In-Place-Upgrade der Hauptversion fehlschlägt.
Führen Sie zur Behebung dieses Problems vor dem Upgrade die Anweisung XA RECOVER aus. Mit dieser Anweisung wird nach nicht committeten XA-Transaktionen gesucht.
Wenn eine Antwort zurückgegeben wird, führen Sie entweder einen Commit für die XA-Transaktionen mit der Anweisung XA COMMIT oder einen Rollback für die XA-Transaktionen mit der Anweisung XA ROLLBACK durch.
Wenn Sie vorhandene XA-Transaktionen prüfen möchten, können Sie einen Befehl ähnlich dem folgenden ausführen:
mysql> XA RECOVER CONVERT xid; +----------+--------------+--------------+-------------------------- | formatID | gtrid_length | bqual_length | data | +----------+--------------+--------------+-------------------------- | 787611 | 9 | 9 | 0x787887111212345678812676152F12345678 | +----------+--------------+--------------+-------------------------- 1 row in set (0.00 sec)
In diesem Beispiel sehen wir, dass die Werte für gtrid und bqual im Hexadezimalformat angegeben, aber fälschlicherweise verkettet wurden. Um dieses Problem zu beheben, müssen Sie diese Werte manuell aus den folgenden Feldern erstellen:
gtrid = 0x787887111212345678bqual = 0x812676152F12345678
Um diese XA-Transaktionen zu committen oder zurückzusetzen, können Sie mit einem Befehl wie dem folgenden eine xid aus diesen Informationen erstellen:
xid: gtrid [, bqual [, formatID ]] mysql> XA ROLLBACK|COMMIT 0x787887111212345678,0x812676152F12345678,787611;
Maximale Schlüssellänge überschritten
Der folgende Fehler tritt auf, wenn ein angegebener Schlüssel zu lang ist:
[ERROR] [MY-013140] [Server] Specified key was too long; max key length is [INTEGER] bytes
Dieser Fehler tritt auf, wenn die angegebene Schlüssellänge das zulässige Limit überschreitet.
Dieses Problem kann durch die sql_mode-Konfiguration verursacht werden. In MySQL-Version 5.7 konnten aufgrund des Fehlens von Strict-Modi Indexe mit Einschränkungen für Präfix oder Indexlänge erstellt werden.
In MySQL 8.0 wurden jedoch strenge Modi wie STRICT_ALL_TABLES oder STRICT_TRANS_TABLES eingeführt, die strengere Regeln für die Indexlänge anwenden und diesen Fehler verursachen.
Um das Problem zu beheben, aktualisieren Sie die Länge des Indexpräfixes auf den in der Fehlermeldung angegebenen maximalen Wert. Beim Standardprotokoll UTFMB4 kann jedes Zeichen bis zu 4 Byte belegen. Die maximale Anzahl von Zeichen lässt sich also ermitteln, indem Sie die maximale Anzahl von Byte durch 4 teilen.
Nicht übereinstimmende Metadaten
Der folgende Fehler tritt auf, wenn die Metadaten nicht übereinstimmen:
[ERROR] [MY-012084] [InnoDB] Num of Indexes in InnoDB doesn't match with Indexes from server [ERROR] [MY-012069] [InnoDB] table: TABLE_NAME has xx columns but InnoDB dictionary has yy columns
In diesem Fall kann auch die folgende Fehlermeldung angezeigt werden:
[ERROR] [MY-010767] [Server] Error in fixing SE data for db_name.table_name
Dieser Fehler tritt auf, wenn Sie versuchen, Tabellen mit nicht übereinstimmenden Metadaten zu aktualisieren.
Wenn Sie beispielsweise versuchen, Tabellen mit nicht übereinstimmenden Metadaten zwischen der FRM-Datei und dem InnoDB-Datendictionary zu aktualisieren, schlägt das Upgrade fehl. In diesem Fall ist die FRM-Datei möglicherweise beschädigt. Um dieses Problem zu beheben, müssen Sie die betroffenen Tabellen exportieren und wiederherstellen, bevor Sie das Upgrade versuchen.
Weitere Informationen finden Sie unter Versuch, Tabellen mit nicht übereinstimmenden Metadaten zu aktualisieren.
Um die betroffenen Tabellen zu exportieren und wiederherzustellen, können Sie einen Befehl wie den folgenden ausführen:
mysqldump --databases database_name --host=$host --user=$user --password=$password > database_dump.sql mysql> source database_dump.sql;
Fremdschlüsselname mit mehr als 64 Zeichen
Der folgende Fehler tritt auf, wenn Sie versuchen, einen Fremdschlüsselnamen zu verwenden, der zu lang ist:
[ERROR] [MY-012054] [InnoDB] Foreign key name:key_name is too long
Dieser Fehler tritt auf, wenn der Name des Fremdschlüssels länger als 64 Zeichen ist.
Um das Problem zu beheben, ermitteln Sie Tabellen mit zu langen Einschränkungsnamen. Verwenden Sie dazu einen Befehl wie den folgenden:
SELECT CONSTRAINT_NAME, TABLE_NAME FROM information_schema.REFERENTIAL_CONSTRAINTS WHERE CHAR_LENGTH(CONSTRAINT_NAME) > 64;
Wenn eine Tabelle einen Einschränkungsnamen mit mehr als 64 Zeichen enthält, verwenden Sie den Befehl ALTER TABLE, um die Einschränkung umzubenennen und das Zeichenlimit einzuhalten:
ALTER TABLE your_table RENAME CONSTRAINT your_long_constraint_name TO your_new_constraint_name;
Nicht übereinstimmende Groß-/Kleinschreibung in Tabellennamen
Der folgende Fehler tritt auf, wenn Sie keine genauen Tabellennamen verwenden:
[ERROR] [MY-013521] [Server] Table name 'SCHEMA_NAME.TABLE_NAME' containing upper case characters is not allowed with lower_case_table_names = 1.
Dieser Fehler tritt auf, wenn die Groß- und Kleinschreibung von Tabellennamen nicht übereinstimmt.
Wenn für Instanzen mit MySQL-Version 5.7 Tabellennamen in Kleinbuchstaben (lower_case_table_names=1) erforderlich sind, müssen alle Tabellennamen in Kleinbuchstaben konvertiert werden, bevor ein Upgrade auf MySQL-Version 8.0 durchgeführt wird.
Alternativ können Sie die Anforderung (lower_case_table_names=0) deaktivieren und dann die Instanz aktualisieren. Wenn Sie den Wert des Felds lower_case_table_names von 1 in 0 ändern, können Sie den Wert in MySQL 8.0 nicht mehr zurückändern.
Von InnoDB erkannte Tabellen, die zu einer anderen Engine gehören
Der folgende Fehler tritt auf, wenn eine Tabelle von InnoDB erkannt wird, sie aber eigentlich zu einer anderen Engine gehört:
Error: Following tables are recognized by InnoDB engine while the SQL layer believes they belong to a different engine. Such situation may happen when one removed InnoDB files manually from the disk and creates a table with same name by using different engine.
Dieser Fehler tritt auf, wenn Sie eine Tabelle löschen und dann eine neue Tabelle mit demselben Namen erstellen, wobei Sie eine andere Engine verwenden.
Wenn es in der Datenbank Tabellen gibt, die von der InnoDB-Engine erkannt werden, aber nicht von der SQL-Ebene, schlägt das Upgrade fehl.
Um dieses Problem zu beheben, suchen Sie alle Tabellen in der Datenbank, die nicht das InnoDB-Speichermodul verwenden:
SELECT * FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'db_name' AND ENGINE != 'InnoDB'
Führen Sie für jede identifizierte Tabelle einen ALTER TABLE-Befehl aus, um die Speichermaschine in InnoDB zu ändern.
ALTER TABLE db_name.table_name ENGINE='INNODB';
Unbekannte Speicher-Engine: partition
Der folgende Fehler tritt auf, wenn Sie versuchen, eine unbekannte Speicher-Engine zu verwenden:
[System] [MY-011012] [Server] Starting upgrade of data directory. [ERROR] [MY-013140] [Server] Unknown storage engine 'partition'
Dieser Fehler tritt auf, wenn in der Engine nicht unterstützte Partitionen vorhanden sind.
In MySQL 8.0 sind nur die folgenden Partitionen in der Speicher-Engine zulässig:
InnoDBndbcluster
Zur Behebung dieses Problems müssen Sie nach Tabellen mit Partitionen suchen, deren Engine nicht InnoDB ist.
Mit der folgenden Abfrage können Sie diese Tabellen ermitteln:
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE NOT IN ('innodb', 'ndbcluster') AND CREATE_OPTIONS LIKE '%partitioned%';
Alle Tabellen, die von der Abfrage gemeldet werden, müssen aktualisiert werden, damit sie InnoDB verwenden, oder so konfiguriert werden, dass sie nicht partitioniert sind. Wenn Sie die Speichermaschine einer Tabelle in InnoDB ändern möchten, führen Sie diese Anweisung aus:
ALTER TABLE db_name.table_name ENGINE = INNODB;
MVU-Vorgang mit langer Ausführungszeit
Mit einem Upgrade auf eine neue Hauptversion sind zwei zugrunde liegende Aufgaben verbunden:
- Vorabprüfung: Gibt einen Zeitüberschreitungsfehler zurück, wenn sie nicht innerhalb von drei Stunden abgeschlossen ist.
- Upgradevorgang: Gibt einen Zeitüberschreitungsfehler zurück, wenn er nicht innerhalb von sechs Stunden abgeschlossen wird.
Wenn für die Instanz ein MAJOR_VERSION_UPGRADE-Vorgang läuft, der länger als erwartet dauert, können Sie die MySQL-Fehlerlogs untersuchen, um zu prüfen, ob der Vorgang bei einem Metadaten-Upgrade blockiert ist oder bei einem Vorabprüfungsschritt hängen bleibt. Die häufigsten Ursachen für dieses Problem sind:
- Eine sehr große Anzahl von Tabellen, Ansichten oder Indexen
- Unzureichende Ressourcen wie CPU oder Arbeitsspeicher
- Wichtige Transaktionen verhindern das Herunterfahren von Datenbanken, damit der Aktualisierungsprozess beginnen kann. Mit der Google Cloud Console können Sie aktuelle Prozesse prüfen.
Zu viele geöffnete Dateien im System
Der folgende Fehler tritt auf, wenn im System zu viele Dateien geöffnet sind:
[ERROR] [MY-012592] [InnoDB] Operating system error number 23 in a file operation [ERROR] [MY-012596] [InnoDB] Error number 23 means 'Too many open files in system'
Dieser Fehler tritt beispielsweise auf, wenn die Instanz mehr als 2 Millionen Tabellen enthält. In diesem Fall erhalten Sie möglicherweise eine Fehlermeldung, die darauf hinweist, dass „zu viele Dateien im System geöffnet sind“.
Reduzieren Sie die Anzahl der Tabellen, bevor Sie das Upgrade durchführen, um dieses Problem zu beheben.
Fehler aufgrund fehlenden Speichers
Der folgende Fehler tritt auf, wenn der Speicherplatz nicht mehr ausreicht:
Out of memory
Dieser Fehler tritt auf, wenn Tabellen nicht genügend Speicher zugewiesen wird.
Beim Upgrade von MySQL 5.7 auf 8.0 ist zusätzlicher Arbeitsspeicher erforderlich, um alte Metadaten in das neue Datenwörterbuch zu konvertieren.
Um dieses Problem zu beheben, empfehlen wir, dass Sie für jede Tabelle mindestens 100 KB Arbeitsspeicher haben.
Mit der folgenden Abfrage können Sie die Anzahl der Tabellen ermitteln:
SELECT table_schema AS 'Database Name', COUNT(*) AS 'Number of Tables' FROM information_schema.tables
Bevor Sie das Upgrade starten, können Sie den Arbeitsspeicher vorübergehend erhöhen, indem Sie den Maschinentyp ändern.
Für Instanzen mit gemeinsam genutztem Kern (z. B. Micro- oder Small-Kerne, einschließlich db-f1-micro, db-g1-small, HA db-f1-micro, HA db-g1-small) sollten Sie während des Upgrades auf eine Instanz mit dediziertem Kern umstellen, um potenzielle ressourcenbezogene Probleme zu vermeiden. Sie können es nach Abschluss des Upgrades wieder downgraden.
MySQL-Herunterfahrfehler
Der folgende Fehler tritt auf, wenn Sie nach einem Absturz versuchen, ein Upgrade durchzuführen:
[ERROR] [MY-012526] [InnoDB] Upgrade after a crash is not supported.
Dieser Fehler tritt auf, wenn ein vorheriges Herunterfahren länger als erwartet gedauert hat.
Cloud SQL führt vor dem Upgrade der Hauptversion ein sauberes Herunterfahren durch. Bei Instanzen mit hohen Arbeitslasten oder lang andauernden Transaktionen kann der Herunterfahrvorgang länger dauern, was möglicherweise zu einem Zeitlimit und einem fehlgeschlagenen Upgrade führt.
Um dieses Problem zu beheben und sicherzustellen, dass das Upgrade erfolgreich ist, planen Sie es für einen Zeitraum mit wenig Traffic und ohne Transaktionen mit langer Ausführungszeit.