Auf dieser Seite werden bekannte Probleme und Inkompatibilitäten beschrieben, die bei einem Upgrade der Hauptversion 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 Vorabprüfungstools und während des Upgrades auftreten können.
Reservierte Keywords
Hier sehen Sie ein Beispiel für eine Fehlermeldung:
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.
Einige Keywords wie GROUPS, LEAD oder RANK werden in MySQL-Version 8.0 jetzt als reserviert eingestuft. Das bedeutet, dass einige Wörter, die zuvor als Kennungen verwendet wurden, jetzt als illegal gelten können. Um betroffene Anweisungen zu korrigieren, verwenden Sie Anführungszeichen für Bezeichner oder benennen Sie den Bezeichner um.
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
Hier sehen Sie ein Beispiel für eine Fehlermeldung:
[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'
Hier ein weiteres Beispiel für eine Fehlermeldung:
[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.
Abfragen, die zuvor auf der GROUP BY-Sortierung basierten, 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.
Wenn 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
Hier sehen Sie ein Beispiel für eine Fehlermeldung:
[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
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. Verwenden Sie eine Abfrage wie die folgende, um räumliche Datenindexe zu ermitteln:
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
Hier sehen Sie ein Beispiel für eine Fehlermeldung:
[ERROR] [MY-010765] [Server] Error in Creating DD entry for %s.%s [ERROR] [MY-013140] [Server] Invalid utf8 character string: invalid_string
Wenn eine Tabellendefinition ungültige UTF-8-Zeichen enthält, kann die Konvertierung der Tabellendefinitionen in das Data Dictionary fehlschlagen. Um dieses Problem zu beheben, ersetzen Sie die ungültigen Zeichen entweder durch die entsprechenden UTF8-Zeichen oder entfernen Sie sie vollständig.
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 zugesicherte XA-Transaktionen
Hier sehen Sie ein Beispiel für eine Fehlermeldung:
[ERROR] [MY-013527] [Server] Upgrade cannot proceed due to an existing prepared XA transactions
Wenn nicht committete XA-Transaktionen vorhanden sind, schlägt das direkte Upgrade der Hauptversion fehl. Um dieses Problem zu beheben, führen Sie 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 der XA-Transaktionen mit der Anweisung XA COMMIT oder einen Rollback der XA-Transaktionen mit der Anweisung XA ROLLBACK durch. Um vorhandene XA-Transaktionen zu prüfen, können Sie einen Befehl wie den 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 anhand der folgenden Felder 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
Hier sehen Sie ein Beispiel für eine Fehlermeldung:
[ERROR] [MY-013140] [Server] Specified key was too long; max key length is [INTEGER] bytes
Dieses Problem kann durch die sql_mode-Konfiguration verursacht werden. In MySQL-Version 5.7 konnten aufgrund des Fehlens von strengen 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 in Byte. 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
Hier sehen Sie ein Beispiel für eine Fehlermeldung:
[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
Hier ein weiteres Beispiel für eine Fehlermeldung:
[ERROR] [MY-010767] [Server] Error in fixing SE data for db_name.table_name
Wenn Sie versuchen, Tabellen mit nicht übereinstimmenden Metadaten zwischen der FRM-Datei und dem InnoDB-Wörterbuch zu aktualisieren, schlägt das Upgrade fehl. In diesem Fall ist die FRM-Datei möglicherweise beschädigt. Um das Problem zu beheben, müssen Sie die betroffenen Tabellen exportieren und wiederherstellen, bevor Sie versuchen, ein Upgrade durchzuführen.
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
Hier sehen Sie ein Beispiel für eine Fehlermeldung:
[ERROR] [MY-012054] [InnoDB] Foreign key name:key_name is too long
Dieser Fehler weist darauf hin, dass Namen von Fremdschlüsseleinschränkungen in Tabellen nicht länger als 64 Zeichen sein dürfen. Um Tabellen mit zu langen Einschränkungsnamen zu identifizieren, können Sie einen Befehl wie den folgenden verwenden:
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
Hier sehen Sie ein Beispiel für eine Fehlermeldung:
[ERROR] [MY-013521] [Server] Table name 'SCHEMA_NAME.TABLE_NAME' containing upper case characters is not allowed with lower_case_table_names = 1.
Wenn für Instanzen mit MySQL-Version 5.7 Kleinbuchstaben für Tabellennamen erforderlich sind (lower_case_table_names=1), müssen alle Tabellennamen in Kleinbuchstaben konvertiert werden, bevor ein Upgrade auf MySQL-Version 8.0 erfolgt.
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
Hier sehen Sie ein Beispiel für eine Fehlermeldung:
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.
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.
So finden 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 erkannte Tabelle einen ALTER TABLE-Befehl aus, um das Speichermodul in InnoDB zu ändern.
ALTER TABLE db_name.table_name ENGINE='INNODB';
Unbekannte Partition der Speicher-Engine
Hier sehen Sie ein Beispiel für eine Fehlermeldung:
[System] [MY-011012] [Server] Starting upgrade of data directory. [ERROR] [MY-013140] [Server] Unknown storage engine 'partition'
In MySQL 8.0 sind keine Partitionen in der Engine außer InnoDB und ndbcluster zulässig. Sie müssen nach Tabellen mit Partitionen suchen, deren Engine nicht InnoDB ist. Führen Sie die folgende Abfrage aus, um diese Tabellen zu ermitteln:
SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE NOT IN ('innodb', 'ndbcluster') AND CREATE_OPTIONS LIKE '%partitioned%';
Jede Tabelle, die von der Abfrage gemeldet wird, muss aktualisiert werden, damit sie InnoDB verwendet, oder so konfiguriert werden, dass sie nicht partitioniert ist. Führen Sie diese Anweisung aus, um das Speichermodul einer Tabelle in InnoDB zu ändern:
ALTER TABLE db_name.table_name ENGINE = INNODB;
MVU-Vorgang mit langer Ausführungszeit
Mit einem Upgrade auf eine 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änger als erwartet ausgeführt wird, 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. Sie können die Trusted Cloud by S3NS Console verwenden, um aktuelle Prozesse zu prüfen.
Zu viele geöffnete Dateien im System
Hier sehen Sie ein Beispiel für eine Fehlermeldung:
[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'
Wenn die Instanz mehr als 2 Millionen Tabellen enthält, erhalten Sie möglicherweise eine Fehlermeldung, die darauf hinweist, dass „zu viele Dateien im System geöffnet sind“. Möglicherweise müssen Sie die Anzahl der Tabellen vor dem Upgrade auf weniger als 2 Millionen reduzieren.
Fehler aufgrund fehlenden Speichers
Beim Upgrade von MySQL 5.7 auf 8.0 ist zusätzlicher Arbeitsspeicher erforderlich, um alte Metadaten in das neue Datenwörterbuch zu konvertieren. Damit beim Upgrade der Hauptversion kein Fehler vom Typ „out of memory“ auftritt, empfiehlt Cloud SQL, dass für jede Tabelle mindestens 100 KB Arbeitsspeicher zur Verfügung stehen.
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
Um das Problem zu beheben, können Sie den Arbeitsspeicher vor dem Start des Upgrades 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
Hier sehen Sie ein Beispiel für eine Fehlermeldung:
[ERROR] [MY-012526] [InnoDB] Upgrade after a crash is not supported.
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. Damit das Upgrade erfolgreich durchgeführt werden kann, sollten Sie es für einen Zeitraum mit geringem Traffic und ohne lang andauernde Transaktionen planen.