Referenz zu Vorabprüfungsbeschreibungen für Aurora MySQL

Stufe der Vorabprüfung: Fehler

Probleme, die vom Befehl check table x for upgrade für das mysql-Schema gemeldet wurden

Bevor das Upgrade auf Aurora-MySQL-Version 3 gestartet wird, wird check table for upgrade für jede Tabelle im mysql-Schema auf der DB-Instance ausgeführt. Der Befehl check table for upgrade untersucht Tabellen auf mögliche Probleme, die bei einem Upgrade auf eine neuere Version von MySQL auftreten könnten. Das Ausführen dieses Befehls vor dem Upgrade kann helfen, etwaige Inkompatibilitäten im Voraus zu identifizieren und zu beheben, sodass der eigentliche Upgrade-Prozess reibungsloser abläuft.

Mit diesem Befehl werden verschiedene Prüfungen für jede Tabelle durchgeführt, z. B. die folgenden:

Weitere Informationen finden Sie unter CHECK-TABLE-Anweisung in der MySQL-Dokumentation.

Beispielausgabe:

{
  "id": "checkTableMysqlSchema",
  "title": "Issues reported by 'check table x for upgrade' command for mysql schema.",
  "status": "OK",
  "detectedProblems": []
}

Die Ausgabe dieser Vorabprüfung hängt davon ab, welcher Fehler aufgetreten ist und wann er aufgetreten ist, da check table for upgrade mehrere Prüfungen durchführt.

Wenn Sie bei dieser Vorabprüfung auf Fehler stoßen, wenden Sie sich an den AWS Support, um die Behebung der Metadaten-Inkonsistenz zu beantragen. Alternativ können Sie das Upgrade erneut versuchen, indem Sie einen logischen Dump durchführen und dann in einem neuen DB-Cluster von Aurora-MySQL-Version 3 wiederherstellen.

Stufe der Vorabprüfung: Fehler

Zirkuläre Verzeichnisverweise in Tablespace-Datendateipfaden

Ab MySQL 8.0.17 erlaubt die Klausel CREATE TABLESPACE ... ADD DATAFILE keine zirkulären Verzeichnisverweise mehr. Entfernen Sie zur Vermeidung von Upgrade-Problemen alle zirkulären Verzeichnisverweise aus den Tablespace-Datendateipfaden, bevor Sie auf Aurora-MySQL-Version 3 aktualisieren.

Beispielausgabe:

{
  "id": "circularDirectory",
  "title": "Circular directory references in tablespace data file paths",
  "status": "OK",
  "description": "Error: Following tablespaces contain circular directory references (e.g. the reference '/../') in data file paths which as of MySQL 8.0.17 are not permitted by the CREATE TABLESPACE ... ADD DATAFILE clause. An exception to the restriction exists on Linux, where a circular directory reference is permitted if the preceding directory is a symbolic link. To avoid upgrade issues, remove any circular directory references from tablespace data file paths before upgrading.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-innodb-changes",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "ts2",
        "description": "circular reference in datafile path: '/home/ec2-user/dbdata/mysql_5_7_44/../ts2.ibd'",
        "dbObjectType": "Tablespace"
      }
  ]
}

Wenn Sie diesen Fehler erhalten, erstellen Sie Ihre Tabellen neu, indem Sie einen Datei-pro-Tabelle-Tablespace verwenden. Verwenden Sie Standarddateipfade für alle Tablespace- und Tabellendefinitionen.

Nach dem Neuerstellen ist die Vorabprüfung erfolgreich, sodass das Upgrade fortgesetzt werden kann.

{
  "id": "circularDirectoryCheck",
  "title": "Circular directory references in tablespace data file paths",
  "status": "OK",
  "detectedProblems": []
},

Stufe der Vorabprüfung: Fehler

Spalten, die keine Standardwerte haben dürfen

Vor MySQL 8.0.13 dürfen BLOB-, TEXT-, GEOMETRY- und JSON-Spalten keine Standardwerte haben. Entfernen Sie alle Standardklauseln in diesen Spalten, bevor Sie ein Upgrade auf Aurora-MySQL-Version 3 durchführen. Weitere Informationen zu Änderungen an der Standardbehandlung für diese Datentypen finden Sie unter Standardwerte für Datentypen in der MySQL-Dokumentation.

Beispielausgabe:

{
  "id": "columnsWhichCannotHaveDefaultsCheck",
  "title": "Columns which cannot have default values",
  "status": "OK",
  "description": "Error: The following columns are defined as either BLOB, TEXT, GEOMETRY or JSON and have a default value set. These data types cannot have default values in MySQL versions prior to 8.0.13, while starting with 8.0.13, the default value must be specified as an expression. In order to fix this issue, please use the ALTER TABLE ... ALTER COLUMN ... DROP DEFAULT statement.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/data-type-defaults.html#data-type-defaults-explicit",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.test_blob_default.geo_col",
        "description": "geometry"
      }
  ]
},

Die Vorabprüfung gibt einen Fehler zurück, weil die Spalte geo_col in der Tabelle test.test_blob_default einen BLOB-, TEXT-, GEOMETRY- oder JSON-Datentyp mit einem angegebenen Standardwert verwendet.

Ein Blick auf die Tabellendefinition zeigt, dass die Spalte geo_col als geo_col geometry NOT NULL default '' definiert ist.

mysql> show create table test_blob_default\G
*************************** 1. row ***************************
       Table: test_blob_default
Create Table: CREATE TABLE `test_blob_default` (
  `geo_col` geometry NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=latin1

Durch das Entfernen dieser Standardklausel kann die Vorabprüfung erfolgreich abgeschlossen werden.

mysql> ALTER TABLE test_blob_default modify COLUMN geo_col geometry NOT NULL;
Query OK, 0 rows affected (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> show create table test_blob_default\G
*************************** 1. row ***************************
       Table: test_blob_default
Create Table: CREATE TABLE `test_blob_default` (
  `geo_col` geometry NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

Die Vorabprüfung ist erfolgreich und Sie können das Upgrade erneut versuchen.

{
  "id": "columnsWhichCannotHaveDefaultsCheck",
  "title": "Columns which cannot have default values",
  "status": "OK",
  "detectedProblems": []
},

Stufe der Vorabprüfung: Fehler

Verwendung von veralteten Schlüsselwörtern in der Definition

MySQL 8.0 hat den Abfrage-Cache entfernt. Infolgedessen wurde ein Teil der für den Abfrage-Cache spezifischen SQL-Syntax entfernt. Wenn eines Ihrer Datenbankobjekte die Schlüsselwörter QUERY CACHE, SQL_CACHE oder SQL_NO_CACHE enthält, wird ein Fehler bei der Vorabprüfung zurückgegeben. Sie beheben dieses Problem, indem Sie diese Objekte erneut erstellen und die genannten Schlüsselwörter entfernen.

Beispielausgabe:

{
  "id": "depreciatedSyntaxCheck",
  "title": "Usage of depreciated keywords in definition",
  "status": "OK",
  "description": "Error: The following DB objects contain keywords like 'QUERY CACHE', 'SQL_CACHE', 'SQL_NO_CACHE' which are not supported in major version 8.0. It is recommended to drop these DB objects or rebuild without any of the above keywords before upgrade.",
  "detectedProblems": [
      {
"level": "Error",
"dbObject": "test.no_query_cache_check",
"description": "PROCEDURE uses depreciated words in definition"
      }
  ]
}

Die Vorabprüfung meldet, dass die gespeicherte Prozedur test.no_query_cache_check eines der entfernten Schlüsselwörter verwendet. Ein Blick auf die Prozedurdefinition zeigt, dass sie SQL_NO_CACHE verwendet.

mysql> show create procedure test.no_query_cache_check\G
*************************** 1. row ***************************
           Procedure: no_query_cache_check
            sql_mode:
    Create Procedure: CREATE DEFINER=`reinvent`@`%` PROCEDURE `no_query_cache_check`()
BEGIN
    SELECT SQL_NO_CACHE k from sbtest1 where id > 10 and id < 20 group by k asc;
END
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

Entfernen Sie das Schlüsselwort.

mysql> drop procedure test.no_query_cache_check;
Query OK, 0 rows affected (0.01 sec)

mysql> delimiter //

mysql> CREATE DEFINER=`reinvent`@`%` PROCEDURE `no_query_cache_check`() BEGIN     SELECT k from sbtest1 where id > 10 and id < 20 group by k asc; END//
Query OK, 0 rows affected (0.00 sec)

mysql> delimiter ;

Nach dem Entfernen des Schlüsselworts wird die Vorabprüfung erfolgreich abgeschlossen.

{
  "id": "depreciatedSyntaxCheck",
  "title": "Usage of depreciated keywords in definition",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Von InnoDB erkannte Tabellen, die zu einer anderen Engine gehören

Ähnlich wie schemaInconsistencyCheck stellt diese Vorabprüfung sicher, dass die Tabellenmetadaten in MySQL konsistent sind, bevor mit dem Upgrade fortgefahren wird.

Wenn Sie bei dieser Vorabprüfung auf Fehler stoßen, wenden Sie sich an den AWS Support, um die Behebung der Metadaten-Inkonsistenz zu beantragen. Alternativ können Sie das Upgrade erneut versuchen, indem Sie einen logischen Dump durchführen und dann in einem neuen DB-Cluster von Aurora-MySQL-Version 3 wiederherstellen.

Beispielausgabe:

{
  "id": "engineMixupCheck",
  "title": "Tables recognized by InnoDB that belong to a different engine",
  "status": "OK",
  "description": "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 removes InnoDB table files manually from the disk and creates e.g. a MyISAM table with the same name.\n\nA possible way to solve this situation is to e.g. in case of MyISAM table:\n\n1. Rename the MyISAM table to a temporary name (RENAME TABLE).\n2. Create some dummy InnoDB table (its definition does not need to match), then copy (copy, not move) and rename the dummy .frm and .ibd files to the orphan name using OS file commands.\n3. The orphan table can be then dropped (DROP TABLE), as well as the dummy table.\n4. Finally the MyISAM table can be renamed back to its original name.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.general_log_backup",
        "description": "recognized by the InnoDB engine but belongs to CSV"
      }
  ]
}

Stufe der Vorabprüfung: Fehler

ENUM- und SET-Spaltendefinitionen mit Elementen, die länger als 255 Zeichen sind

Tabellen und gespeicherte Prozeduren dürfen keine ENUM- oder SET-Spaltenelemente enthalten, die 255 Zeichen oder 1 020 Byte überschreiten. Vor MySQL 8.0 betrug die maximale kombinierte Länge 64 KB, aber 8.0 begrenzt einzelne Elemente auf 255 Zeichen oder 1 020 Byte (mit Unterstützung für Multibyte). Wenn bei der Vorabprüfung für enumSetElementLengthCheck ein Fehler auftritt, ändern Sie alle Elemente, die diese neuen Grenzwerte überschreiten, bevor Sie das Upgrade erneut versuchen.

Beispielausgabe:

{
  "id": "enumSetElementLengthCheck",
  "title": "ENUM/SET column definitions containing elements longer than 255 characters",
  "status": "OK",
  "description": "Error: The following columns are defined as either ENUM or SET and contain at least one element longer that 255 characters. They need to be altered so that all elements fit into the 255 characters limit.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/string-type-overview.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.large_set.s",
        "description": "SET contains element longer than 255 characters"
      }
  ]
},

Bei der Vorabprüfung wird ein Fehler gemeldet, da die Spalte s in der Tabelle test.large_set ein SET-Element mit mehr als 255 Zeichen enthält.

Nach dem Reduzieren der SET-Größe für diese Spalte ist die Vorabprüfung erfolgreich, sodass das Upgrade fortgesetzt werden kann.

{
  "id": "enumSetElementLenghtCheck",
  "title": "ENUM/SET column definitions containing elements longer than 255 characters",
  "status": "OK",
  "detectedProblems": []
},

Stufe der Vorabprüfung: Fehler

Namen für Fremdschlüsseleinschränkungen mit mehr als 64 Zeichen

In MySQL ist die Länge von Bezeichnern auf 64 Zeichen begrenzt, wie in der MySQL-Dokumentation beschrieben. Aufgrund von Problemen, bei denen Fremdschlüssellängen diesem Wert entsprechen oder diesen überschreiten könnten, was zu Upgrade-Fehlern führte, wurde diese Vorabprüfung implementiert. Wenn bei dieser Vorabprüfung Fehler auftreten, sollten Sie Ihre Einschränkung ändern oder umbenennen, sodass sie weniger als 64 Zeichen umfasst, bevor Sie das Upgrade erneut versuchen.

Beispielausgabe:

{
  "id": "foreignKeyLength",
  "title": "Foreign key constraint names longer than 64 characters",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Alle Triggernamen in einer Datenbank müssen eindeutig sein.

Aufgrund von Änderungen in der Implementierung des Datenwörterbuchs unterstützt MySQL 8.0 in einer Datenbank keine Trigger, bei denen zwischen Groß- und Kleinschreibung unterschieden wird. Diese Vorabprüfung validiert, dass Ihr DB-Cluster keine Datenbanken mit doppelten Triggern enthält. Weitere Informationen finden Sie unter Groß- und Kleinschreibung von Bezeichnern in der MySQL-Dokumentation.

Beispielausgabe:

{
  "id": "getDuplicateTriggers",
  "title": "MySQL pre-checks that all trigger names in a database are unique or not.",
  "status": "OK",
  "description": "Error: You have one or more database containing duplicate triggers. Mysql 8.0 does not support case sensitive triggers within a database https://dev.mysql.com/doc/refman/8.0/en/identifier-case-sensitivity.html. To upgrade to MySQL 8.0, drop the triggers with case-insensitive duplicate names and recreate with distinct names.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test",
        "description": "before_insert_product"
      },
      {
        "level": "Error",
        "dbObject": "test",
        "description": "before_insert_PRODUCT"
      }
  ]
}

Bei der Vorabprüfung wird ein Fehler gemeldet, dass der Datenbank-Cluster zwei Trigger mit demselben Namen enthält, jedoch in unterschiedlicher Groß- und Kleinschreibung: test.before_insert_product und test.before_insert_PRODUCT.

Benennen Sie die Trigger vor dem Upgrade um oder löschen Sie sie und erstellen Sie sie mit einem neuen Namen neu.

Nach dem Umbenennen von test.before_insert_PRODUCT in test.before_insert_product_2 ist die Vorabprüfung erfolgreich.

{
  "id": "getDuplicateTriggers",
  "title": "MySQL pre-checks that all trigger names in a database are unique or not.",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Die Definer-Spalte für mysql.event darf weder Null noch leer sein.

Das DEFINER-Attribut gibt das MySQL-Konto an, das Eigentümer einer gespeicherten Objektdefinition ist, z. B. eines Triggers, einer gespeicherten Prozedur oder eines Ereignisses. Dieses Attribut ist besonders nützlich in Situationen, in denen Sie den Sicherheitskontext kontrollieren möchten, in dem das gespeicherte Objekt ausgeführt wird. Wenn beim Erstellen eines gespeicherten Objekts kein DEFINER angegeben wird, wird standardmäßig der Benutzer verwendet, der das Objekt erstellt hat.

Beim Upgrade auf MySQL 8.0 dürfen sich keine gespeicherten Objekte im MySQL-Datenwörterbuch befinden, die einen null- oder leeren Definer aufweisen. Wenn solche gespeicherten Objekte vorhanden sind, wird ein Fehler bei der Vorabprüfung ausgelöst. Sie müssen diesen beheben, bevor das Upgrade fortgesetzt werden kann.

Fehlerbeispiel:

{
  "id": "getEventsWithNullDefiner",
  "title": "The definer column for mysql.event cannot be null or blank.",
  "status": "OK",
  "description": "Error: Set definer column in mysql.event to a valid non-null definer.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.get_version",
        "description": "Set definer for event get_version in Schema test"
      }
  ]
}

Die Vorabprüfung gibt einen Fehler für das test.get_version-Ereignis zurück, da es einen null-Definer aufweist.

Zum Beheben dieses Problems können Sie die Ereignisdefinition überprüfen. Wie Sie sehen können, ist der Definer null oder leer.

mysql> select db,name,definer from mysql.event where name='get_version';
+------+-------------+---------+
| db   | name        | definer |
+------+-------------+---------+
| test | get_version |         |
+------+-------------+---------+
1 row in set (0.00 sec)

Löschen Sie das Ereignis oder erstellen Sie es mit einem gültigen Definer neu.

mysql> drop event test.get_version;
Query OK, 0 rows affected (0.00 sec)

mysql> DELIMITER ;
mysql> delimiter $$
mysql> CREATE EVENT get_version
    ->     ON SCHEDULE
    ->       EVERY 1 DAY
    ->     DO
    ->      ///DO SOMETHING //
    -> $$
Query OK, 0 rows affected (0.01 sec)

mysql> DELIMITER ;

mysql> select db,name,definer from mysql.event where name='get_version';
+------+-------------+------------+
| db   | name        | definer    |
+------+-------------+------------+
| test | get_version | reinvent@% |
+------+-------------+------------+
1 row in set (0.00 sec)

Die Vorabprüfung ist jetzt erfolgreich.

{
  "id": "getEventsWithNullDefiner",
  "title": "The definer column for mysql.event cannot be null or blank.",
  "status": "OK",
  "detectedProblems": []},

Stufe der Vorabprüfung: Fehler

Nichtübereinstimmung von Spaltendefinitionen zwischen dem InnoDB-Datenwörterbuch und der tatsächlichen Tabellendefinition

Ähnlich wie schemaInconsistencyCheck stellt diese Vorabprüfung sicher, dass die Tabellenmetadaten in MySQL konsistent sind, bevor mit dem Upgrade fortgefahren wird. In diesem Fall stellt die Vorabprüfung sicher, dass die Spaltendefinitionen zwischen dem InnoDB-Datenwörterbuch und der MySQL-Tabellendefinition übereinstimmen. Wenn eine Nichtübereinstimmung festgestellt wird, wird das Upgrade nicht fortgesetzt.

Wenn Sie bei dieser Vorabprüfung auf Fehler stoßen, wenden Sie sich an den AWS Support, um die Behebung der Metadaten-Inkonsistenz zu beantragen. Alternativ können Sie das Upgrade erneut versuchen, indem Sie einen logischen Dump durchführen und dann in einem neuen DB-Cluster von Aurora-MySQL-Version 3 wiederherstellen.

Beispielausgabe:

{
  "id": "getMismatchedMetadata",
  "title": "Column definition mismatch between InnoDB Data Dictionary and actual table definition.",
  "status": "OK",
  "description": "Error: Your database has mismatched metadata. The upgrade to mysql 8.0 will not succeed until this is fixed.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.mismatchTable",
        "description": "Table `test/mismatchTable` column names mismatch with InnoDb dictionary column names: iD <> id"
      }
  ]
}

Bei der Vorabprüfung wird eine Nichtübereinstimmung in den Metadaten für die Spalte id in der Tabelle test.mismatchTable gemeldet. Insbesondere führen die MySQL-Metadaten die Spalte als iD, InnoDB hingegen als id.

Stufe der Vorabprüfung: Fehler

Die Definer-Spalte für information_schema.triggers darf nicht null oder leer sein.

Die Vorabprüfung validiert, dass Ihre Datenbank keine Trigger enthält, die mit null- oder leeren Definern definiert sind. Weitere Informationen zu den Definer-Anforderungen für gespeicherte Objekte finden Sie unter getEventsWithNullDefiner.

Beispielausgabe:

{
  "id": "getTriggersWithNullDefiner",
  "title": "The definer column for information_schema.triggers cannot be null or blank.",
  "status": "OK",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.example_trigger",
        "description": "Set definer for trigger example_trigger in Schema test"
      }
  ]
}

Die Vorabprüfung gibt einen Fehler zurück, da der Trigger example_trigger im test-Schema über einen null-Definer verfügt. Zur Behebung dieses Problems sollte der Definer korrigiert werden, indem der Trigger mit einem gültigen Benutzer neu erstellt oder entfernt wird. Weitere Informationen finden Sie im Beispiel in getEventsWithNullDefiner.

Stufe der Vorabprüfung: Fehler

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

Vor MySQL 8.0 entsprachen Datenbanknamen, Tabellennamen und andere Objekte Dateien im Datenverzeichnis, wie z. B. dateibasierten Metadaten (.frm). Mit der Systemvariablen lower_case_table_names können Benutzer steuern, wie der Server die Groß- und Kleinschreibung von Bezeichnern bei Datenbankobjekten behandelt und wie solche Metadatenobjekte gespeichert werden. Dieser Parameter könnte auf einem bereits initialisierten Server nach einem Neustart geändert werden.

In MySQL 8.0 steuert dieser Parameter zwar weiterhin, wie der Server die Groß- und Kleinschreibung von Bezeichnern behandelt, er kann jedoch nicht geändert werden, nachdem das Datenwörterbuch initialisiert wurde. Beim Upgrade oder der Erstellung einer MySQL-8.0-Datenbank wird der Wert, der für lower_case_table_names beim ersten Start des Datenwörterbuchs in MySQL festgelegt wird, für die gesamte Lebensdauer dieser Datenbank verwendet. Diese Einschränkung wurde im Rahmen der Implementierung des Atomic Data Dictionary eingeführt, bei der Datenbankobjekte von dateibasierten Metadaten zu internen InnoDB-Tabellen im mysql-Schema migriert werden.

Weitere Informationen finden Sie unter Änderungen am Datenwörterbuch in der MySQL-Dokumentation.

Um Probleme während dem Upgrade bei der Aktualisierung dateibasierter Metadaten auf das neue Atomic Data Dictionary zu vermeiden, validiert diese Vorabprüfung, dass bei lower_case_table_names = 1 alle Tabellen in Kleinbuchstaben auf der Festplatte gespeichert sind. Wenn dies nicht der Fall ist, wird ein Fehler bei der Vorabprüfung zurückgegeben und Sie müssen die Metadaten korrigieren, bevor Sie mit dem Upgrade fortfahren können.

Beispielausgabe:

{
  "id": "getValueOfVariablelower_case_table_names",
  "title": "MySQL pre-checks that all database or table names are lowercase when the lower_case_table_names parameter is set to 1.",
  "status": "OK",
  "description": "Error: You have one or more databases or tables with uppercase letters in the names, but the lower_case_table_names parameter is set to 1. To upgrade to MySQL 8.0, either change all database or table names to lowercase, or set the parameter to 0.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.TEST",
        "description": "Table test.TEST contains one or more capital letters in name while lower_case_table_names = 1"
      }
  ]
}

Ein Fehler wird zurückgegeben, da die Tabelle test.TEST Großbuchstaben enthält, aber lower_case_table_names auf 1 gesetzt ist.

Zum Beheben dieses Problems können Sie die Tabelle umbenennen, sodass Kleinbuchstaben verwendet werden, oder Sie können den Parameter lower_case_table_names im DB-Cluster ändern, bevor Sie mit dem Upgrade beginnen.

Stufe der Vorabprüfung: Fehler

Verwendung einer entfernten GROUP BY ASC/DESC-Syntax

Ab MySQL 8.0.13 wurde die veraltete ASC- oder DESC-Syntax für GROUP BY-Klauseln entfernt. Abfragen, die auf der GROUP BY-Sortierung basieren, können jetzt unterschiedliche Ergebnisse liefern. Um eine bestimmte Sortierreihenfolge zu erhalten, verwenden Sie stattdessen eine ORDER BY-Klausel. Wenn in Ihrer Datenbank Objekte existieren, die diese Syntax verwenden, müssen Sie sie mithilfe einer ORDER BY-Klausel neu erstellen, bevor Sie das Upgrade erneut versuchen. Weitere Informationen finden Sie unter SQL-Änderungen in der MySQL-Dokumentation.

Beispielausgabe:

{
  "id": "groupbyAscSyntaxCheck",
  "title": "Usage of removed GROUP BY ASC/DESC syntax",
  "status": "OK",
  "description": "Error: The following DB objects use removed GROUP BY ASC/DESC syntax. They need to be altered so that ASC/DESC keyword is removed from GROUP BY clause and placed in appropriate ORDER BY clause.",
  "documentationLink": "https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-13.html#mysqld-8-0-13-sql-syntax",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.groupbyasc",
        "description": "PROCEDURE uses removed GROUP BY ASC syntax",
        "dbObjectType": "Routine"
      }
  ]
}

Stufe der Vorabprüfung: Fehler

Suchen Sie nach veralteter .<table>-Syntax, die in Routinen verwendet wird.

In MySQL 8.0 dürfen Routinen keine veraltete Bezeichnersyntax (\".<table>\") mehr enthalten. Wenn gespeicherte Routinen oder Trigger solche Bezeichner enthalten, schlägt das Upgrade fehl. Die folgende .dot_table-Referenz ist beispielsweise nicht mehr zulässig:

mysql> show create procedure incorrect_procedure\G
*************************** 1. row ***************************
           Procedure: incorrect_procedure
            sql_mode:
    Create Procedure: CREATE DEFINER=`reinvent`@`%` PROCEDURE `incorrect_procedure`()
BEGIN delete FROM .dot_table; select * from .dot_table where 1=1; END
character_set_client: utf8mb4
collation_connection: utf8mb4_0900_ai_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

Nachdem Sie die Routinen und Trigger neu erstellt haben, um die korrekte Bezeichnersyntax und das richtige Maskieren zu verwenden, ist die Vorabprüfung erfolgreich und das Upgrade kann fortgesetzt werden. Weitere Informationen finden Sie unter Namen von Schemaobjekten in der MySQL-Dokumentation.

Beispielausgabe:

{
  "id": "mysqlEmptyDotTableSyntaxCheck",
  "title": "Check for deprecated '.<table>' syntax used in routines.",
  "status": "OK",
  "description": "Error: The following routines contain identifiers in deprecated identifier syntax (\".<table>\"), and should be corrected before upgrade:\n",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.incorrect_procedure",
        "description": " routine body contains deprecated identifiers."
      }
  ]
}

Die Vorabprüfung gibt einen Fehler für die incorrect_procedure-Routine in der test-Datenbank zurück, da sie eine veraltete Syntax enthält.

Nachdem Sie die Routine korrigiert haben, ist die Vorabprüfung erfolgreich und Sie können das Upgrade erneut versuchen.

Stufe der Vorabprüfung: Fehler

Prüfen auf Indizes, die zu groß sind, um mit MySQL-Versionen höher als 5.7 zu funktionieren

Bei kompakten oder redundanten Zeilenformaten sollte es nicht möglich sein, einen Index mit einem Präfix von mehr als 767 Byte zu erstellen. Vor der MySQL-Version 5.7.35 war dies jedoch möglich. Weitere Informationen finden Sie unter Versionshinweise für MySQL 5.7.35.

Auf alle Indizes, die von diesem Fehler betroffen waren, kann nach dem Upgrade auf MySQL 8.0 nicht mehr zugegriffen werden. Diese Vorabprüfung identifiziert fehlerhafte Indizes, die neu erstellt werden müssen, bevor das Upgrade fortgesetzt werden kann.

 {
  "id": "mysqlIndexTooLargeCheck",
  "title": "Check for indexes that are too large to work on higher versions of MySQL Server than 5.7",
  "status": "OK",
  "description": "Error: The following indexes ware made too large for their format in an older version of MySQL (older than 5.7.34). Normally those indexes within tables with compact or redundant row formats shouldn't be larger than 767 bytes. To fix this problem those indexes should be dropped before upgrading or those tables will be inaccessible.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.table_with_large_idx",
        "description": "IDX_2"
      }
  ]
}

Die Vorabprüfung gibt einen Fehler zurück, da die Tabelle test.table_with_large_idx einen Index für eine Tabelle mit kompaktem oder redundantem Zeilenformat enthält, dessen Größe 767 Byte überschreitet. Auf diese Tabellen kann nach dem Upgrade auf MySQL 8.0 nicht mehr zugegriffen werden. Führen Sie einen der folgenden Schritte aus, bevor Sie mit dem Upgrade fortfahren:

Hier erstellen wir die Tabelle neu, um den Fehler bei der Vorabprüfung zu beheben. Vergewissern Sie sich vor dem Neuerstellen der Tabelle, dass innodb_file_format auf Barracuda und innodb_default_row_format auf dynamic gesetzt ist. Dies sind die Standardwerte in MySQL 5.7. Weitere Informationen finden Sie unter InnoDB-Zeilenformate und InnoDB-Dateiformatverwaltung in der MySQL-Dokumentation.

mysql > select @@innodb_file_format,@@innodb_default_row_format;
+----------------------+-----------------------------+
| @@innodb_file_format | @@innodb_default_row_format |
+----------------------+-----------------------------+
| Barracuda            | dynamic                     |
+----------------------+-----------------------------+
1 row in set (0.00 sec)

mysql> optimize table table_with_large_idx;
+---------------------------+----------+----------+-------------------------------------------------------------------+
| Table                     | Op       | Msg_type | Msg_text                                                          |
+---------------------------+----------+----------+-------------------------------------------------------------------+
| test.table_with_large_idx | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.table_with_large_idx | optimize | status   | OK                                                                |
+---------------------------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.02 sec)

# Verify FILE_FORMAT and ROW_FORMAT
mysql>  select * from information_schema.innodb_sys_tables where name like 'test/table_with_large_idx';
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
| TABLE_ID | NAME                      | FLAG | N_COLS | SPACE | FILE_FORMAT | ROW_FORMAT | ZIP_PAGE_SIZE | SPACE_TYPE |
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
|       43 | test/table_with_large_idx |   33 |      4 |    26 | Barracuda   | Dynamic    |             0 | Single     |
+----------+---------------------------+------+--------+-------+-------------+------------+---------------+------------+
1 row in set (0.00 sec)

Nach dem Neuerstellen der Tabelle ist die Vorabprüfung erfolgreich und das Upgrade kann fortgesetzt werden.

{
  "id": "mysqlIndexTooLargeCheck",
  "title": "Check for indexes that are too large to work on higher versions of MySQL Server than 5.7",
  "status": "OK",
  "detectedProblems": []
},

Stufe der Vorabprüfung: Fehler

Prüfen auf ungültige Tabellen- und Schemanamen, die in MySQL 5.7 verwendet wurden

Bei der Migration zum neuen Datenwörterbuch in MySQL 8.0 darf Ihre Datenbank-Instance keine Schemas oder Tabellen enthalten, die mit dem Präfix #mysql50# versehen sind. Wenn solche Objekte existieren, schlägt das Upgrade fehl. Führen Sie zum Beheben dieses Problems mysqlcheck für die zurückgegebenen Schemas und Tabellen aus.

Beispielausgabe:

{
  "id": "mysqlInvalid57NamesCheck",
  "title": "Check for invalid table names and schema names used in 5.7",
  "status": "OK",
  "description": "The following tables and/or schemas have invalid names. In order to fix them use the mysqlcheck utility as follows:\n\n  $ mysqlcheck --check-upgrade --all-databases\n  $ mysqlcheck --fix-db-names --fix-table-names --all-databases\n\nOR via mysql client, for eg:\n\n  ALTER DATABASE `#mysql50#lost+found` UPGRADE DATA DIRECTORY NAME;",
  "documentationLink": "https://dev.mysql.com/doc/refman/5.7/en/identifier-mapping.html https://dev.mysql.com/doc/refman/5.7/en/alter-database.html https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "#mysql50#fix_db_names",
        "description": "Schema name"
      }
  ]
}

Die Vorabprüfung meldet, dass das Schema #mysql50#fix_db_names einen ungültigen Namen hat.

Nach der Korrektur des Schemanamens ist die Vorabprüfung erfolgreich, sodass das Upgrade fortgesetzt werden kann.

{
  "id": "mysqlInvalid57NamesCheck",
  "title": "Check for invalid table names and schema names used in 5.7",
  "status": "OK",
  "detectedProblems": []
},

Stufe der Vorabprüfung: Fehler

Prüfen auf verwaiste Routinen in 5.7

Wenn bei der Migration zum neuen Datenwörterbuch in MySQL 8.0 gespeicherte Prozeduren in der Datenbank vorhanden sind, in denen das Schema nicht mehr existiert, schlägt das Upgrade fehl. Diese Vorabprüfung stellt sicher, dass alle Schemas, auf die in gespeicherten Prozeduren in Ihrer DB-Instance verwiesen wird, noch vorhanden sind. Löschen Sie diese gespeicherten Prozeduren, damit das Upgrade fortgesetzt werden kann.

Beispielausgabe:

{
  "id": "mysqlOrphanedRoutinesCheck",
  "title": "Check for orphaned routines in 5.7",
  "status": "OK",
  "description": "Error: The following routines have been orphaned. Schemas that they are referencing no longer exists.\nThey have to be cleaned up or the upgrade will fail.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "dropped_db.get_version",
        "description": "is orphaned"
      }
  ]
},

Die Vorabprüfung meldet, dass die gespeicherte Prozedur get_version in der dropped_db-Datenbank verwaist ist.

Zur Bereinigung dieser Prozedur können Sie das fehlende Schema neu erstellen.

mysql> create database dropped_db;
Query OK, 1 row affected (0.01 sec)

Nachdem das Schema neu erstellt wurde, können Sie die Prozedur löschen, damit das Upgrade fortgesetzt werden kann.

{
  "id": "mysqlOrphanedRoutinesCheck",
  "title": "Check for orphaned routines in 5.7",
  "status": "OK",
  "detectedProblems": []
},

Stufe der Vorabprüfung: Fehler

Tabellennamen im mysql-Schema kollidieren mit neuen Tabellen in MySQL 8.0

Das neue Atomic Data Dictionary, das in MySQL 8.0 eingeführt wurde, speichert alle Metadaten in einer Reihe interner InnoDB-Tabellen im mysql-Schema. Während des Upgrades werden die neuen internen Datenwörterbuchtabellen im mysql-Schema erstellt. Zur Vermeidung von Namenskonflikten, die zu Upgrade-Fehlern führen würden, untersucht die Vorabprüfung alle Tabellennamen im mysql-Schema, um sicherzustellen, dass keiner der neuen Tabellennamen bereits verwendet wird. Falls doch, wird ein Fehler zurückgegeben und das Upgrade kann nicht fortgesetzt werden.

Beispielausgabe:

{
  "id": "mysqlSchema",
  "title": "Table names in the mysql schema conflicting with new tables in the latest MySQL.",
  "status": "OK",
  "description": "Error: The following tables in mysql schema have names that will conflict with the ones introduced in the latest version. They must be renamed or removed before upgrading (use RENAME TABLE command). This may also entail changes to applications that use the affected tables.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrade-before-you-begin.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.tablespaces",
        "description": "Table name used in mysql schema.",
        "dbObjectType": "Table"
      }
  ]
}

Ein Fehler wird zurückgegeben, da im mysql-Schema bereits eine Tabelle mit dem Namen tablespaces existiert. Dies ist einer der neuen Tabellennamen für interne Datenwörterbücher in MySQL 8.0. Sie müssen solche Tabellen vor dem Upgrade mithilfe des Befehls RENAME TABLE umbenennen oder entfernen.

Stufe der Vorabprüfung: Fehler

Partitionierte Tabellen mit Engines ohne nativer Partitionierung

Laut der MySQL-8.0-Dokumentation bieten derzeit zwei Speicher-Engines native Partitionierungsunterstützung: InnoDB und NDB. Von diesen wird nur InnoDB in Aurora-MySQL-Version 3 unterstützt, kompatibel mit MySQL 8.0. Jeder Versuch, partitionierte Tabellen in MySQL 8.0 mit einer anderen Speicher-Engine zu erstellen, schlägt fehl. Diese Vorabprüfung sucht nach Tabellen in Ihrem DB-Cluster, die eine nicht-native Partitionierung verwenden. Wenn welche zurückgegeben werden, müssen Sie die Partitionierung entfernen oder die Speicher-Engine in InnoDB konvertieren.

Beispielausgabe:

{
  "id": "nonNativePartitioning",
  "title": "Partitioned tables using engines with non native partitioning",
  "status": "OK",
  "description": "Error: In the latest MySQL storage engine is responsible for providing its own partitioning handler, and the MySQL server no longer provides generic partitioning support. InnoDB and NDB are the only storage engines that provide a native partitioning handler that is supported in the latest MySQL. A partitioned table using any other storage engine must be altered—either to convert it to InnoDB or NDB, or to remove its partitioning—before upgrading the server, else it cannot be used afterwards.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-configuration-changes",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.partMyisamTable",
         "description": "MyISAM engine does not support native partitioning",
         "dbObjectType": "Table"
      }
  ]
}

Hier verwendet eine MyISAM-Tabelle Partitionierung, was eine Aktion erfordert, bevor das Upgrade fortgesetzt werden kann.

Stufe der Vorabprüfung: Fehler

Verwendung eines alten temporalen Typs

„Alte Temporale“ beziehen sich auf Spalten mit temporalen Typen (wie TIMESTAMP undDATETIME), die in MySQL-Versionen 5.5 und niedriger erstellt wurden. In MySQL 8.0 wurde die Unterstützung für diese alten temporalen Datentypen entfernt, was bedeutet, dass direkte Upgrades von MySQL 5.7 auf 8.0 nicht möglich sind, wenn die Datenbank diese alten temporalen Datentypen enthält. Zum Beheben dieses Problems müssen Sie alle Tabellen, die solche alten temporalen Datentypen enthalten, neu erstellen, bevor Sie mit dem Upgrade fortfahren.

Weitere Informationen zur Einstellung alter temporaler Datentypen in MySQL 5.7 finden Sie in diesem Blog. Weitere Informationen zur Entfernung alter temporaler Datentypen in MySQL 8.0 finden Sie in diesem Blog.

Beispielausgabe:

{
  "id": "oldTemporalCheck",
  "title": "Usage of old temporal type",
  "status": "OK",
  "description": "Error: Following table columns use a deprecated and no longer supported temporal disk storage format. They must be converted to the new format before upgrading. It can by done by rebuilding the table using 'ALTER TABLE <table_name> FORCE' command",
  "documentationLink": "https://dev.mysql.com/blog-archive/mysql-8-0-removing-support-for-old-temporal-datatypes/",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.55_temporal_table.timestamp_column",
        "description": "timestamp /* 5.5 binary format */",
        "dbObjectType": "Column"
      }
  ]
},

Für die Spalte timestamp_column in der Tabelle test.55_temporal_table wird ein Fehler gemeldet, da sie ein altes temporales Festplattenspeicherformat verwendet, das nicht mehr unterstützt wird.

Um dieses Problem zu beheben und das Upgrade fortsetzen zu können, erstellen Sie die Tabelle neu, um das alte temporale Festplattenspeicherformat in das neue Format zu konvertieren, das in MySQL 5.6 eingeführt wurde. Weitere Informationen und Voraussetzungen dafür finden Sie unter Konvertierung zwischen 3-Byte- und 4-Byte-Unicode-Zeichensätzen in der MySQL-Dokumentation.

Wenn Sie den folgenden Befehl ausführen, um die in dieser Vorabprüfung genannten Tabellen neu zu erstellen, werden die alten temporalen Typen mit einer Genauigkeit von Sekundenbruchteilen in das neuere Format konvertiert.

ALTER TABLE ... ENGINE=InnoDB;

Weitere Informationen finden Sie unter ALTER-TABLE-Anweisung in der MySQL-Dokumentation.

Nachdem Sie die fragliche Tabelle neu erstellt und das Upgrade neu gestartet haben, ist die Kompatibilitätsprüfung erfolgreich, sodass das Upgrade fortgesetzt werden kann.

{
  "id": "oldTemporalCheck",
  "title": "Usage of old temporal type",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Verwendung partitionierter Tabellen in freigegebenen Tablespaces

Ab MySQL 8.0.13 wurde die Unterstützung für das Platzieren von Tabellenpartitionen in freigegebenen Tablespaces entfernt. Verschieben Sie vor dem Upgrade alle derartigen Tabellen von freigegebenen Tablespaces in Datei-pro-Tabelle-Tablespaces.

Beispielausgabe:

{
  "id": "partitionedTablesInSharedTablespaceCheck",
  "title": "Usage of partitioned tables in shared tablespaces",
  "status": "OK",
  "description": "Error: The following tables have partitions in shared tablespaces. They need to be moved to file-per-table tablespace before upgrading. You can do this by running query like 'ALTER TABLE table_name REORGANIZE PARTITION X INTO (PARTITION X VALUES LESS THAN (30) TABLESPACE=innodb_file_per_table);'",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.partInnoDBTable",
        "description": "Partition p1 is in shared tablespace innodb",
        "dbObjectType": "Table"
      }
  ]
}

Die Vorabprüfung schlägt fehl, weil sich die Partition p1 aus der Tabelle test.partInnoDBTable im System-Tablespace befindet.

Zum Beheben dieses Problems erstellen Sie die Tabelle test.partInnodbTable neu und platzieren die fehlerhafte Partition p1 in einem Datei-pro-Tabelle-Tablespace.

mysql > ALTER TABLE partInnodbTable REORGANIZE PARTITION p1
    ->   INTO (PARTITION p1 VALUES LESS THAN ('2014-01-01') TABLESPACE=innodb_file_per_table);
Query OK, 0 rows affected, 1 warning (0.02 sec)
Records: 0  Duplicates: 0  Warnings: 0

Danach ist die Vorabprüfung erfolgreich.

{
  "id": "partitionedTablesInSharedTablespaceCheck",
  "title": "Usage of partitioned tables in shared tablespaces",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Verwendung von Funktionen, die aus der neuesten MySQL-Version entfernt wurden

In MySQL 8.0 wurden eine Reihe von integrierten Funktionen entfernt. Bei dieser Vorabprüfung wird Ihre Datenbank auf Objekte untersucht, die diese Funktionen verwenden könnten. Wenn sie gefunden werden, wird ein Fehler zurückgegeben. Sie müssen die Probleme beheben, bevor Sie das Upgrade erneut versuchen können.

Bei den meisten entfernten Funktionen handelt es sich um Geofunktionen, die durch äquivalente ST_*-Funktionen ersetzt wurden. In diesen Fällen ändern Sie die Datenbankobjekte so, dass sie die neue Prozedurbenennung verwenden. Weitere Informationen finden Sie unter In MySQL 8.0 entfernte Funktionen in der MySQL-Dokumentation.

Beispielausgabe:

{
  "id": "removedFunctionsCheck",
  "title": "Usage of removed functions",
  "status": "OK",
  "description": "Error: The following DB objects use functions that were removed in the latest MySQL version. Please make sure to update them to use supported alternatives before upgrade.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.GetLocationsInPolygon",
        "description": "PROCEDURE uses removed function POLYGONFROMTEXT (consider using ST_POLYGONFROMTEXT instead)",
        "dbObjectType": "Routine"
      },
      {
        "level": "Error",
        "dbObject": "test.InsertLocation",
        "description": "PROCEDURE uses removed function POINTFROMTEXT (consider using ST_POINTFROMTEXT instead)",
        "dbObjectType": "Routine"
      }
  ]
},

Die Vorabprüfung meldet, dass die gespeicherte Prozedur test.GetLocationsInPolygon zwei entfernte Funktionen verwendet: POLYGONFROMTEXT und POINTFROMTEXT. Außerdem wird empfohlen, die neuen ST_POLYGONFROMTEXT und ST_POINTFROMTEXT als Ersatz zu verwenden. Nachdem Sie die Prozedur anhand der Vorschläge neu erstellt haben, wird die Vorabprüfung erfolgreich abgeschlossen.

{
  "id": "removedFunctionsCheck",
  "title": "Usage of removed functions",
  "status": "OK",
  "detectedProblems": []
},

Stufe der Vorabprüfung: Fehler

MySQL-Syntaxprüfung für routinenähnliche Objekte

MySQL 8.0 hat reservierte Schlüsselwörter eingeführt, die zuvor nicht reserviert waren. Die Upgrade-Vorabprüfung wertet die Verwendung reservierter Schlüsselwörter in den Namen von Datenbankobjekten sowie in deren Definitionen und Körper aus. Wenn sie feststellt, dass reservierte Schlüsselwörter in Datenbankobjekten wie gespeicherten Prozeduren, Funktionen, Ereignissen und Triggern verwendet werden, schlägt das Upgrade fehl und ein Fehler wird in der Datei upgrade-prechecks.log veröffentlicht. Zum Beheben des Problems müssen Sie diese Objektdefinitionen aktualisieren und alle derartigen Referenzen vor dem Upgrade in einfache Anführungszeichen (') setzen. Weitere Informationen zum Maskieren reservierter Wörter in MySQL finden Sie unter Zeichenfolgenliterale in der MySQL-Dokumentation.

Alternativ können Sie den Namen in einen anderen Namen ändern, was möglicherweise Änderungen an der Anwendung erforderlich macht.

Beispielausgabe:

{
  "id": "routineSyntaxCheck",
  "title": "MySQL syntax check for routine-like objects",
  "status": "OK",
  "description": "The following objects did not pass a syntax check with the latest MySQL 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'",
         "dbObjectType": "Routine"
      }
  ]
}

Zum Beheben dieses Problems überprüfen Sie die Routinedefinition.

SHOW CREATE PROCEDURE test.select_res_word\G

*************************** 1. row ***************************
           Procedure: select_res_word
            sql_mode: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
    Create Procedure: CREATE PROCEDURE 'select_res_word'()
BEGIN
    SELECT * FROM except;
END
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

Die Prozedur verwendet eine Tabelle mit dem Namen except, was ein neues Schlüsselwort in MySQL 8.0 ist. Erstellen Sie die Prozedur neu, indem Sie das Zeichenfolgenliteral maskieren.

> drop procedure if exists select_res_word;
Query OK, 0 rows affected (0.00 sec)

> DELIMITER $$
 > CREATE PROCEDURE select_res_word()
    -> BEGIN
    ->     SELECT * FROM 'except';
    -> END$$
Query OK, 0 rows affected (0.00 sec)

 > DELIMITER ;

Die Vorabprüfung ist jetzt erfolgreich.

{
  "id": "routineSyntaxCheck",
  "title": "MySQL syntax check for routine-like objects",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Schemainkonsistenzen, die auf das Entfernen oder die Beschädigung von Dateien zurückzuführen sind

Wie bereits beschrieben, wurde mit MySQL 8.0 das Atomic Data Dictionary eingeführt, das alle Metadaten in einer Reihe interner InnoDB-Tabellen im mysql-Schema speichert. Diese neue Architektur bietet eine transaktionale, ACID-konforme Methode zur Verwaltung von Datenbankmetadaten und löst damit das „atomare DDL“-Problem des alten dateibasierten Ansatzes. Vor MySQL 8.0 konnten Schemaobjekte verwaisen, wenn eine DDL-Operation unerwartet unterbrochen wurde. Durch die Migration von dateibasierten Metadaten zu den neuen Tabellen des Atomic Data Dictionary während des Upgrades wird sichergestellt, dass es in der DB-Instance keine solchen verwaisten Schemaobjekte gibt. Wenn verwaiste Objekte gefunden werden, schlägt das Upgrade fehl.

Damit diese verwaisten Objekte vor dem Start des Upgrades leichter erkannt werden können, wird die Vorabprüfung schemaInconsistencyCheck durchgeführt, um sicherzustellen, dass alle Metadatenobjekte des Datenwörterbuchs synchron sind. Wenn verwaiste Metadatenobjekte erkannt werden, wird das Upgrade nicht fortgesetzt. Bereinigen Sie diese verwaisten Metadatenobjekte, um mit dem Upgrade fortzufahren.

Wenn Sie bei dieser Vorabprüfung auf Fehler stoßen, wenden Sie sich an den AWS Support, um die Behebung der Metadaten-Inkonsistenz zu beantragen. Alternativ können Sie das Upgrade erneut versuchen, indem Sie einen logischen Dump durchführen und dann in einem neuen DB-Cluster von Aurora-MySQL-Version 3 wiederherstellen.

Beispielausgabe:

{
  "id": "schemaInconsistencyCheck",
  "title": "Schema inconsistencies resulting from file removal or corruption",
  "status": "OK",
  "description": "Error: Following tables show signs that either table datadir directory or frm file was removed/corrupted. Please check server logs, examine datadir to detect the issue and fix it before upgrade",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.schemaInconsistencyCheck_failure",
        "description": "present in INFORMATION_SCHEMA's INNODB_SYS_TABLES table but missing from TABLES table"
      }
  ]
}

Die Vorabprüfung meldet, dass die Tabelle test.schemaInconsistencyCheck_failure inkonsistente Metadaten enthält. In diesem Fall ist die Tabelle in den InnoDB-Speicher-Engine-Metadaten (information_schema.INNODB_SYS_TABLES) vorhanden, aber nicht in den MySQL-Metadaten (information_schema.TABLES).

Stufe der Vorabprüfung: Fehler

Prüfen auf Artefakte im Zusammenhang mit der Aurora-Funktion für die DDL-Wiederherstellung

Im Rahmen der Wiederherstellungsimplementierung der Data Definition Language (DDL) in Aurora MySQL werden Metadaten zu Inflight-DDL-Anweisungen in den Tabellen ddl_log_md_table und ddl_log_table im mysql-Schema verwaltet. Auroras Implementierung der DDL-Wiederherstellung wird ab Version 3 nicht unterstützt, da die Funktionalität Teil der neuen Implementierung des Atomic Data Dictionary in MySQL 8.0 ist. Wenn während der Kompatibilitätsprüfungen DDL-Anweisungen ausgeführt werden, schlägt diese Vorabprüfung möglicherweise fehl. Wir empfehlen, das Upgrade auszuprobieren, während keine DDL-Anweisungen ausgeführt werden.

Wenn diese Vorabprüfung fehlschlägt, ohne dass DDL-Anweisungen ausgeführt werden, wenden Sie sich an den AWS Support, um die Behebung der Metadaten-Inkonsistenz zu beantragen. Alternativ können Sie das Upgrade erneut versuchen, indem Sie einen logischen Dump durchführen und dann in einem neuen DB-Cluster von Aurora-MySQL-Version 3 wiederherstellen.

Wenn DDL-Anweisungen ausgeführt werden, zeigt die Ausgabe der Vorabprüfung folgende Meldung an:

“There are DDL statements in process. Please allow DDL statements to finish before upgrading.”

Beispielausgabe:

{
  "id": "auroraCheckDDLRecovery",
  "title": "Check for artifacts related to Aurora DDL recovery feature",
  "status": "OK",
  "description": "Aurora implementation of DDL recovery is not supported from 3.x onwards. This check verifies that the database do not have artifacts realted to the feature",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "mysql.ddl_log_md_table",
        "description": "Table mysql.ddl_log_md_table is not empty. Your database has pending DDL recovery operations. Reachout to AWS support for assistance."
      },
      {
        "level": "Error",
        "dbObject": "mysql.ddl_log_table",
        "description": "Table mysql.ddl_log_table is not empty. Your database has pending DDL recovery operations. Reachout to AWS support for assistance."
      },
      {
        "level": "Error",
        "dbObject": "information_schema.processlist",
        "description": "There are DDL statements in process. Please allow DDL statements to finish before upgrading."
      }
  ]
}

Die Vorabprüfung hat einen Fehler zurückgegeben, da eine Inflight-DDL gleichzeitig mit den Kompatibilitätsprüfungen ausgeführt wurde. Wir empfehlen, dass Sie das Upgrade erneut versuchen, ohne dass DDLs ausgeführt werden.

Stufe der Vorabprüfung: Fehler

Prüfen der Existenz der Tabelle mysql.rds_upgrade_prechecks

Dies ist eine rein interne Vorabprüfung, die vom RDS-Service durchgeführt wird. Alle Fehler werden beim Upgrade automatisch behandelt und können problemlos ignoriert werden.

Wenn Sie bei dieser Vorabprüfung auf Fehler stoßen, wenden Sie sich an den AWS Support, um die Behebung der Metadaten-Inkonsistenz zu beantragen. Alternativ können Sie das Upgrade erneut versuchen, indem Sie einen logischen Dump durchführen und dann in einem neuen DB-Cluster von Aurora-MySQL-Version 3 wiederherstellen.

{
  "id": "auroraCheckRdsUpgradePrechecksTable",
  "title": "Check existence of mysql.rds_upgrade_prechecks table",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Prüfen auf Artefakte im Zusammenhang mit der Aurora-Funktion für schnelle DDL

Die Optimierung für schnelle DDL wurde im Labormodus für Aurora-MySQL-Version 2 eingeführt, um die Effizienz einiger DDL-Operationen zu verbessern. In Aurora-MySQL-Version 3 wurde der Labormodus entfernt und die Implementierung schneller DDL wurde durch die MySQL-8.0-Funktion namens Sofortige DDL ersetzt.

Vor dem Upgrade auf Aurora-MySQL-Version 3 müssen alle Tabellen, die schnelle DDL im Labormodus verwenden, neu erstellt werden, indem der Befehl OPTIMIZE TABLE oder ALTER TABLE ... ENGINE=InnoDB ausgeführt wird, um die Kompatibilität mit Aurora-MySQL-Version 3 sicherzustellen.

Diese Vorabprüfung gibt eine Liste solcher Tabellen zurück. Nachdem die zurückgegebenen Tabellen neu erstellt wurden, können Sie das Upgrade erneut versuchen.

Beispielausgabe:

{
  "id": "auroraFODUpgradeCheck",
  "title": "Check for artifacts related to Aurora fast DDL feature",
  "status": "OK",
  "description": "Aurora fast DDL is not supported from 3.x onwards. This check verifies that the database does not have artifacts related to the feature",
  "documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FastDDL.html#AuroraMySQL.Managing.FastDDL-v2",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.test",
        "description": "Your table has pending Aurora fast DDL operations. Run 'OPTIMIZE TABLE <table name>' for the table to apply all the pending DDL updates. Then try the upgrade again."
      }
  ]
}

Die Vorabprüfung meldet, dass in der Tabelle test.test ausstehende Operationen für schnelle DDL vorhanden sind.

Damit das Upgrade fortgesetzt werden kann, können Sie die Tabelle neu erstellen und dann das Upgrade erneut versuchen.

mysql> optimize table test.test;
+-----------+----------+----------+-------------------------------------------------------------------+
| Table     | Op       | Msg_type | Msg_text                                                          |
+-----------+----------+----------+-------------------------------------------------------------------+
| test.test | optimize | note     | Table does not support optimize, doing recreate + analyze instead |
| test.test | optimize | status   | OK                                                                |
+-----------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.04 sec)

Nach dem Neuerstellen der Tabelle ist die Vorabprüfung erfolgreich.

{
  "id": "auroraFODUpgradeCheck",
  "title": "Check for artifacts related to Aurora fast DDL feature",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Tabellen mit hängender FULLTEXT-Indexreferenz

Vor MySQL 5.6.26 war es möglich, dass die versteckten Spalten FTS_DOC_ID und FTS_DOC_ID_INDEX nach dem Löschen eines Volltextsuchindex verwaisen würden. Weitere Informationen finden Sie unter Fehler #76012.

Wenn Sie Tabellen haben, die in früheren Versionen von MySQL erstellt wurden, bei denen dies aufgetreten ist, kann dies dazu führen, dass Upgrades auf Aurora-MySQL-Version 3 fehlschlagen. Diese Vorabprüfung stellt vor dem Upgrade auf MySQL 8.0 sicher, dass in Ihrem DB-Cluster keine solchen verwaisten oder „hängenden“ Volltextindizes existieren. Wenn diese Vorabprüfung fehlschlägt, erstellen Sie alle Tabellen neu, die solche hängenden Volltextindizes enthalten.

Beispielausgabe:

{
  "id": "auroraGetDanglingFulltextIndex",
  "title": "Tables with dangling FULLTEXT index reference",
  "status": "OK",
  "description": "Error: The following tables contain dangling FULLTEXT index which is not supported. It is recommended to rebuild the table before upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.table_with_fts_index",
        "description": "Table `test.table_with_fts_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
      }
  ]
},

Die Vorabprüfung meldet einen Fehler für die Tabelle test.table_with_fts_index, da sie einen hängenden Volltextindex enthält. Damit das Upgrade fortgesetzt werden kann, müssen Sie die Tabelle neu erstellen, um die Hilfstabellen für den Volltextindex zu bereinigen. Verwenden Sie OPTIMIZE TABLE test.table_with_fts_index oder ALTER TABLE test.table_with_fts_index, ENGINE=INNODB.

Nach dem Neuerstellen der Tabelle ist die Vorabprüfung erfolgreich.

{
  "id": "auroraGetDanglingFulltextIndex",
  "title": "Tables with dangling FULLTEXT index reference",
  "status": "OK",
  "detectedProblems": []
},

Stufe der Vorabprüfung: Fehler

Prüfen auf Inkonsistenzen im Zusammenhang mit dem ibd-Dateipfad

Diese Vorabprüfung gilt nur für Aurora-MySQL-Version 3.03.0 und niedriger. Wenn Sie bei dieser Vorabprüfung auf einen Fehler stoßen, versuchen Sie ein Upgrade auf Aurora-MySQL-Version 3.04 oder höher.

Beispielausgabe:

{
  "id": "auroraUpgradeCheckForDatafilePathInconsistency",
  "title": "Check for inconsistency related to ibd file path.",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Prüfen auf einen Volltextindex mit der Space-ID als Null

Wenn Sie in MySQL einer InnoDB-Tabelle einen Volltextindex hinzufügen, werden eine Reihe von zusätzlichen Index-Tablespaces erstellt. Aufgrund eines Fehlers in früheren Versionen von MySQL, der in Version 5.6.20 behoben wurde, war es möglich, dass diese zusätzlichen Indextabellen im System-Tablespace und nicht in ihrem eigenen InnoDB-Tablespace erstellt wurden.

Wenn solche zusätzlichen Tablespaces existieren, schlägt das Upgrade fehl. Erstellen Sie die im Fehler bei der Vorabprüfung genannten Volltextindizes neu und versuchen Sie dann das Upgrade erneut.

Beispielausgabe:

{
  "id": "auroraUpgradeCheckForFtsSpaceIdZero",
  "title": "Check for fulltext index with space id as zero",
  "status": "OK",
  "description": "The auxiliary tables of FTS indexes on the table are created in system table-space. Due to this DDL queries executed on MySQL8.0 shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.fts_space_zero_check",
        "description": " The auxiliary tables of FTS indexes on the table 'test.fts_space_zero_check' are created in system table-space due to https://bugs.mysql.com/bug.php?id=72132. In MySQL8.0, DDL queries executed on this table shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade."
      }
  ]
},

Die Vorabprüfung meldet einen Fehler für die Tabelle test.fts_space_zero_check, da sie zusätzliche Tabellen für Volltextsuchen (Full-Text Search, FTS) im System-Tablespace enthält.

Nachdem Sie die mit dieser Tabelle verknüpften FTS-Indizes gelöscht und neu erstellt haben, ist die Vorabprüfung erfolgreich.

{
 "id": "auroraUpgradeCheckForFtsSpaceIdZero",
 "title": "Check for fulltext index with space id as zero",
 "status": "OK",
 "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Prüfen auf XA-Transaktionen im vorbereiteten Zustand

Während des Upgrade-Prozesses für die Hauptversion ist es wichtig, dass die DB-Instance von Aurora-MySQL-Version 2 ordnungsgemäß heruntergefahren wird. Dadurch wird sichergestellt, dass alle Transaktionen festgeschrieben oder rückgängig gemacht werden und dass InnoDB alle Undo-Protokolleinträge bereinigt hat. Da ein Transaktions-Rollback notwendig ist, kann das ordnungsgemäße Herunterfahren blockiert werden, wenn Ihre Datenbank XA-Transaktionen im vorbereiteten Zustand enthält. Aus diesem Grund kann das Upgrade nicht fortgesetzt werden, wenn vorbereitete XA-Transaktionen erkannt werden, bis Sie Maßnahmen ergreifen, um sie entweder festzuschreiben oder rückgängig zu machen.

Weitere Informationen zum Auffinden von XA-Transaktionen im vorbereiteten Zustand mithilfe von XA RECOVER finden Sie unter XA-Transaktions-SQL-Anweisungen in der MySQL-Dokumentation. Weitere Informationen zu XA-Transaktionszuständen finden Sie unter XA-Transaktionszustände in der MySQL-Dokumentation.

Beispielausgabe:

{
  "id": "auroraUpgradeCheckForIncompleteXATransactions",
  "title": "Pre-checks for XA Transactions in prepared state.",
  "status": "OK",
  "description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "all",
        "description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions."
      }
  ]
}

Diese Vorabprüfung meldet einen Fehler, da sich Transaktionen im vorbereiteten Zustand befinden, die entweder festgeschrieben oder rückgängig gemacht werden sollten.

Nachdem Sie sich bei der Datenbank angemeldet haben, können Sie in der Tabelle information_schema.innodb_trx und in der XA RECOVER-Ausgabe nach weiteren Informationen suchen.

mysql> select trx_started,
    trx_mysql_thread_id,
    trx_id,trx_state,
    trx_operation_state,
    trx_rows_modified,
    trx_rows_locked 
from 
    information_schema.innodb_trx;
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| trx_started         | trx_mysql_thread_id | trx_id  | trx_state | trx_operation_state | trx_rows_modified | trx_rows_locked |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
| 2024-08-12 01:09:39 |                   0 | 2849470 | RUNNING   | NULL                |                 1 |               0 |
+---------------------+---------------------+---------+-----------+---------------------+-------------------+-----------------+
1 row in set (0.00 sec)

mysql> xa recover;
+----------+--------------+--------------+--------+
| formatID | gtrid_length | bqual_length | data   |
+----------+--------------+--------------+--------+
|        1 |            6 |            0 | xatest |
+----------+--------------+--------------+--------+
1 row in set (0.00 sec)

In diesem Fall machen wir die vorbereitete Transaktion rückgängig.

mysql> XA ROLLBACK 'xatest';
Query OK, 0 rows affected (0.00 sec)
v
mysql> xa recover;
Empty set (0.00 sec)

Nachdem die XA-Transaktion rückgängig gemacht wurde, ist die Vorabprüfung erfolgreich.

{
  "id": "auroraUpgradeCheckForIncompleteXATransactions",
  "title": "Pre-checks for XA Transactions in prepared state.",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Prüfen, ob das Upgrade für die aktuelle Instance-Klasse unterstützt wird

Die Ausführung eines direkten Upgrades von Aurora-MySQL-Version 2.12.0 oder 2.12.1, bei der die Schreiber-DB-Instance-Klasse db.r6i.32xlarge ist, wird derzeit nicht unterstützt. In diesem Fall gibt die Vorabprüfung einen Fehler zurück. Damit das Upgrade fortgesetzt werden kann, können Sie Ihre DB-Instance-Klasse entweder in db.r6i.24xlarge oder kleiner ändern. Oder Sie können ein Upgrade auf Aurora-MySQL-Version 2.12.2 oder höher durchführen, wobei das direkte Upgrade auf Aurora-MySQL-Version 3 auf db.r6i.32xlarge unterstützt wird.

Beispielausgabe:

{
  "id": "auroraUpgradeCheckForInstanceLimit",
  "title": "Checks if upgrade is supported on the current instance class",
  "status": "OK",
  "description": "Upgrade from Aurora Version 2.12.0 and 2.12.1 may fail for 32.xl and above instance class.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "all",
        "description": "Upgrade is not supported on this instance size for Aurora MySql Version 2.12.1. Before upgrading to Aurora MySql 3, please consider either: 1. Changing the instance class to 24.xl or lower. -or- 2. Upgrading to patch version 2.12.2 or higher."
      }
  ]
},

Die Vorabprüfung gibt einen Fehler zurück, da die Schreiber-DB-Instance die Instance-Klasse db.r6i.32xlarge verwendet und auf Aurora-MySQL-Version 2.12.1 läuft.

Stufe der Vorabprüfung: Fehler

Prüfen auf interne Benutzer von Version 8.0

Diese Vorabprüfung gilt nur für Aurora-MySQL-Version 3.03.0 und niedriger. Wenn Sie bei dieser Vorabprüfung auf einen Fehler stoßen, versuchen Sie ein Upgrade auf Aurora-MySQL-Version 3.04 oder höher.

Beispielausgabe:

{
  "id": "auroraUpgradeCheckForInternalUsers",
  "title": "Check for 8.0 internal users.",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Prüfen auf ungültige utf8mb3-Zeichen in einer Ansichtsdefinition

Diese Vorabprüfung identifiziert Ansichten, die Kommentare mit ungültiger utf8mb3-Zeichenkodierung enthalten. In MySQL 8.0 wird eine strengere Validierung auf die Zeichenkodierung in Metadaten angewendet, einschließlich Ansichtskommentaren. Wenn eine Ansichtsdefinition Zeichen enthält, die im utf8mb3-Zeichensatz nicht gültig sind, schlägt das Upgrade fehl.

Zum Beheben dieses Problems ändern Sie die Ansichtsdefinition so, dass alle Nicht-BMP-Zeichen entfernt oder ersetzt werden, bevor Sie versuchen, das Upgrade durchzuführen.

Beispielausgabe:

{
"id": "auroraUpgradeCheckForInvalidUtf8mb3CharacterStringInViews",
"title": "Check for invalid utf8mb3 character string.",
"status": "OK",
"description": "Definition of following view(s) has/have invalid utf8mb3 character string.",
"detectedProblems": [
        {
            "level": "Error",
            "dbObject": "precheck.utf8mb3_invalid_char_view",
            "description": "Definition of view precheck.utf8mb3_invalid_char_view contains an invalid utf8mb3 character string. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify the view definition to not use non-BMP characters and try the upgrade again."
        }
    ]
},

Die Vorabprüfung meldet, dass die Definition der Ansichtsdefinition utf8mb3_invalid_char_view ungültige utf8mb3-Zeichen enthält.

Zum Beheben dieses Problems identifizieren Sie die Ansicht, die die nicht unterstützten Zeichen enthält, und aktualisieren die Kommentare. Untersuchen Sie zunächst die Struktur der Ansicht und identifizieren Sie Kommentare.

MySQL> SHOW CREATE VIEW precheck.utf8mb3_invalid_char_view\G
*************************** 1. row ***************************
                View: utf8mb3_invalid_char_view
        Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`admin`@`%` SQL SECURITY DEFINER VIEW `utf8mb3_invalid_char_view` AS select 'This row contains a dolphin 🐬' AS `message`
character_set_client: utf8
collation_connection: utf8_general_ci
1 row in set, 1 warning (0.00 sec)

Sobald Sie die Ansicht identifiziert haben, die den Fehler enthält, ersetzen Sie sie mithilfe der CREATE OR REPLACE VIEW-Anweisung.

MySQL> CREATE OR REPLACE VIEW precheck.utf8mb3_invalid_char_view AS select 'This view definition to not use non-BMP characters' AS message;

Nach der Aktualisierung aller Ansichtsdefinitionen, die nicht unterstützte Zeichen enthalten, ist die Vorabprüfung erfolgreich und das Upgrade kann fortgesetzt werden.

{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Prüfen auf ungültige utf8mb3-Spaltenkommentare

Diese Vorabprüfung identifiziert Tabellen, die Spaltenkommentare mit ungültiger utf8mb3-Zeichenkodierung enthalten. In MySQL 8.0 wird eine strengere Validierung auf die Zeichenkodierung in Metadaten angewendet, einschließlich Spaltenkommentaren. Wenn Spaltenkommentare Zeichen enthalten, die im utf8mb3-Zeichensatz nicht gültig sind, schlägt das Upgrade fehl.

Zum Beheben dieses Problems müssen Sie die Spaltenkommentare ändern, um alle Nicht-BMP-Zeichen zu entfernen oder zu ersetzen, bevor Sie das Upgrade durchführen. Sie können die ALTER TABLE-Anweisung verwenden, um die Spaltenkommentare zu aktualisieren.

Beispielausgabe:

{
  "id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
  "title": "Check for invalid utf8mb3 column comments.",
  "status": "OK",
  "description": "Following table(s) has/have invalid utf8mb3 comments on the column/columns.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.t2",
        "description": "Table test.t2 has invalid utf8mb3 comments in it's column/columns. This is due to non-BMP characters in the comment field. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
      }
  ]
}

Die Vorabprüfung meldet, dass die Tabelle test.t2 ungültige utf8mb3-Zeichen in einem oder mehreren Spaltenkommentaren enthält, insbesondere aufgrund des Vorhandenseins von Nicht-BMP-Zeichen.

Zum Beheben dieses Problems können Sie die problematischen Spalten identifizieren und ihre Kommentare aktualisieren. Untersuchen Sie zunächst die Tabellenstruktur, um Spalten mit Kommentaren zu identifizieren:

mysql> SHOW CREATE TABLE test.t2\G

Sobald Sie die Spalten mit problematischen Kommentaren identifiziert haben, aktualisieren Sie sie mithilfe der ALTER TABLE-Anweisung. Zum Beispiel:

mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT 'Updated comment without non-BMP characters';

Alternativ können Sie den Kommentar auch vollständig entfernen:

mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT '';

Nach der Aktualisierung aller problematischen Spaltenkommentare ist die Vorabprüfung erfolgreich und das Upgrade kann fortgesetzt werden:

{
  "id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
  "title": "Check for invalid utf8mb3 column comments.",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Prüfen auf ungültige utf8mb3-Indexkommentare

Diese Vorabprüfung identifiziert Tabellen, die Indexkommentare mit ungültiger utf8mb3-Zeichenkodierung enthalten. In MySQL 8.0 wird eine strengere Validierung auf die Zeichenkodierung in Metadaten angewendet, einschließlich Indexkommentaren. Wenn ein Indexkommentar Zeichen enthält, die im utf8mb3-Zeichensatz nicht gültig sind, schlägt das Upgrade fehl.

Zum Beheben dieses Problems müssen Sie die Indexkommentare ändern, um alle Nicht-BMP-Zeichen zu entfernen oder zu ersetzen, bevor Sie das Upgrade durchführen.

Beispielausgabe:

{
    "id": "auroraUpgradeCheckForInvalidUtf8mb3IndexComments",
    "title": "Check for invalid utf8mb3 index comments.",
    "status": "OK",
    "description": "Following table(s) has/have invalid utf8mb3 comments on the index.",
    "detectedProblems": [
        {
            "level": "Error",
            "dbObject": "precheck.utf8mb3_tab_index_comment",
            "description": "Table precheck.utf8mb3_tab_index_comment has invalid utf8mb3 comments in it's index. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
        }
    ]
},

Die Vorabprüfung meldet, dass die Tabelle utf8mb3_tab_index_comment ungültige utf8mb3-Zeichen in einem oder mehreren Spaltenkommentaren enthält, insbesondere aufgrund des Vorhandenseins von Nicht-BMP-Zeichen.

Zum Beheben dieses Problems untersuchen Sie zunächst die Tabellenstruktur, um den Index mit problematischen Kommentaren zu identifizieren.

MySQL> SHOW CREATE TABLE precheck.utf8mb3_tab_index_comment\G
*************************** 1. row ***************************
    Table: utf8mb3_tab_index_comment
Create Table: CREATE TABLE `utf8mb3_tab_index_comment` (
`id` int(11) DEFAULT NULL,
`name` varchar(100) DEFAULT NULL,
KEY `idx_name` (`name`) COMMENT 'Name index 🐬'
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.01 sec)

Sobald Sie den Index identifiziert haben, der Kommentare enthält, die nicht unterstützte Zeichen verwenden, löschen Sie den Index und erstellen Sie ihn neu.

MySQL> ALTER TABLE precheck.utf8mb3_tab_index_comment DROP INDEX idx_name;
MySQL> ALTER TABLE precheck.utf8mb3_tab_index_comment ADD INDEX idx_name(name);

Das folgende Beispiel zeigt eine andere Möglichkeit, den Index neu zu erstellen.

MySQL> ALTER TABLE utf8mb3_tab_index_comment DROP INDEX idx_name, ADD INDEX idx_name (name) COMMENT 'Updated comment without non-BMP characters';

Nachdem Sie alle nicht unterstützten Indexkommentare entfernt oder aktualisiert haben, ist die Vorabprüfung erfolgreich und das Upgrade kann fortgesetzt werden.

{
"id": "auroraUpgradeCheckForInvalidUtf8mb3IndexComments",
"title": "Check for invalid utf8mb3 index comments.",
"status": "OK",
"detectedProblems": []
},

Stufe der Vorabprüfung: Fehler

Prüfen auf ungültige utf8mb3-Zeichen in einer Tabellendefinition

Diese Vorabprüfung identifiziert Tabellen, die Kommentare mit ungültiger utf8mb3-Zeichenkodierung enthalten. In MySQL 8.0 wird eine strengere Validierung auf die Zeichenkodierung in Metadaten angewendet, einschließlich Tabellenkommentaren. Wenn ein Tabellenkommentar Zeichen enthält, die im utf8mb3-Zeichensatz nicht gültig sind, schlägt das Upgrade fehl.

Zum Beheben dieses Problems müssen Sie die Tabellenkommentare ändern, um alle Nicht-BMP-Zeichen zu entfernen oder zu ersetzen, bevor Sie das Upgrade durchführen.

Beispielausgabe:

{
    "id": "auroraUpgradeCheckForInvalidUtf8mb3TableComments",
    "title": "Check for invalid utf8mb3 table comments.",
    "status": "OK",
    "description": "Following table(s) has/have invalid utf8mb3 comments.",
    "detectedProblems": [
        {
            "level": "Error",
            "dbObject": "precheck.utf8mb3_table_with_comment",
            "description": "Table precheck.utf8mb3_table_with_comment has invalid utf8mb3 comments. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
        }
        
    ]
},

Die Vorabprüfung meldet ungültige utf8mb3-Kommentare, die für die utf8mb3_table_with_comment-Tabellen in der Testdatenbank definiert wurden.

Zum Beheben dieses Problems identifizieren Sie die Tabelle, die nicht unterstützte Zeichen enthält, und aktualisieren die Kommentare. Untersuchen Sie zunächst die Struktur der Tabelle und identifizieren Sie die Kommentare.

MySQL> SHOW CREATE TABLE precheck.utf8mb3_table_with_comment\G
*************************** 1. row ***************************
    Table: utf8mb3_table_with_comment
Create Table: CREATE TABLE `utf8mb3_table_with_comment` (
`id` int(11) NOT NULL,
`name` varchar(100) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='This table comment contains flag 🏳️'
1 row in set (0.00 sec)

Sobald Sie Tabellenkommentare identifiziert haben, die nicht unterstützte Zeichen enthalten, aktualisieren Sie die Kommentare mit der ALTER TABLE-Anweisung.

MySQL> ALTER TABLE precheck.utf8mb3_table_with_comment COMMENT='Updated comment without non-BMP characters';

Alternativ können Sie den Kommentar auch entfernen.

MySQL> ALTER TABLE precheck.utf8mb3_table_with_comment COMMENT='';

Nachdem Sie alle nicht unterstützten Zeichen aus allen Tabellenkommentaren entfernt haben, ist die Vorabprüfung erfolgreich.

{
"id": "auroraUpgradeCheckForInvalidUtf8mb3TableComments",
"title": "Check for invalid utf8mb3 table comments.",
"status": "OK",
"detectedProblems": []
},

Stufe der Vorabprüfung: Fehler

Prüfen, ob ein RDS-Master-Benutzer existiert

MySQL 8 hat ein neues Berechtigungsmodell mit Unterstützung für Rollen und dynamische Berechtigungen hinzugefügt, um die Verwaltung von Berechtigungen einfacher und feiner abgestuft zu gestalten. Im Rahmen dieser Änderung hat Aurora MySQL die neue rds_superuser_role eingeführt, die dem Master-Benutzer der Datenbank beim Upgrade von Aurora-MySQL-Version 2 auf Version 3 automatisch gewährt wird.

Weitere Informationen zu den Rollen und Berechtigungen, die dem Master-Benutzer in Aurora MySQL zugewiesen sind, finden Sie unter Berechtigungen von Hauptbenutzerkonten. Weitere Informationen zum rollenbasierten Berechtigungsmodell in Aurora-MySQL-Version 3 finden Sie unter Rollenbasiertes Berechtigungsmodell.

Diese Vorabprüfung stellt sicher, dass der Master-Benutzer in der Datenbank vorhanden ist. Wenn der Master-Benutzer nicht vorhanden ist, schlägt die Vorabprüfung fehl. Damit das Upgrade fortgesetzt werden kann, müssen Sie den Master-Benutzer neu erstellen, indem Sie das Master-Benutzerpasswort zurücksetzen oder den Benutzer manuell erstellen. Versuchen Sie anschließend das Upgrade erneut. Weitere Informationen zum Zurücksetzen des Master-Benutzerpassworts finden Sie unter Ändern des Passworts für den Master-Benutzer der Datenbank.

Beispielausgabe:

{
  "id": "auroraUpgradeCheckForMasterUser",
  "title": "Check if master user exists",
  "status": "OK",
  "description": "Throws error if master user has been dropped!",
  "documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.MasterAccounts.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "all",
        "description": "Your Master User on host '%' has been dropped. To proceed with the upgrade, recreate the master user `reinvent` on default host '%'"
      }
  ]
}

Nachdem Sie Ihr Master-Benutzerpasswort zurückgesetzt haben, ist die Vorabprüfung erfolgreich und Sie können das Upgrade erneut versuchen.

Im folgenden Beispiel wird die AWS CLI zum Zurücksetzen des Passworts verwendet. Passwortänderungen werden sofort übernommen.

aws rds modify-db-cluster \
    --db-cluster-identifier my-db-cluster \
    --master-user-password my-new-password

Anschließend ist die Vorabprüfung erfolgreich.

{
  "id": "auroraUpgradeCheckForMasterUser",
  title": "Check if master user exists",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Prüfen auf Geometriespalten in Präfixindizes

Ab MySQL 8.0.12 können Sie mit dem Datentyp GEOMETRY keinen Präfix-Index mehr für eine Spalte erstellen. Weitere Informationen finden Sie unter WL#11808.

Wenn solche Indizes existieren, schlägt Ihr Upgrade fehl. Zum Beheben des Problems löschen Sie die Präfix-GEOMETRY-Indizes in den Tabellen, die im Fehler bei der Vorabprüfung genannt wurden.

Beispielausgabe:

{
  "id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
  "title": "Check for geometry columns on prefix indexs",
  "status": "OK",
  "description": "Consider dropping the prefix Indexes of geometry columns and restart the upgrade.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.geom_index_prefix",
        "description": "Table `test`.`geom_index_prefix` has an index `LatLon` 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 `LatLon` ON `test`.`geom_index_prefix`;"
      }
  ]
}

Die Vorabprüfung meldet einen Fehler, da die Tabelle test.geom_index_prefix einen Index mit einem Präfix in einer GEOMETRY-Spalte enthält.

Nachdem Sie diesen Index gelöscht haben, ist die Vorabprüfung erfolgreich.

{
  "id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
  "title": "Check for geometry columns on prefix indexs",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Prüfen auf Inkonsistenzen im Zusammenhang mit Sonderzeichen in gespeicherten Prozeduren

Vor MySQL 8.0 entsprachen Datenbanknamen, Tabellennamen und andere Objekte Dateien im Datenverzeichnis, also dateibasierten Metadaten. Im Rahmen des Upgrades auf MySQL 8.0 werden alle Datenbankobjekte zu den neuen internen Datenwörterbuchtabellen migriert, die im mysql-Schema gespeichert sind, um das neu implementierte Atomic Data Dictionary zu unterstützen. Im Rahmen der Migration von gespeicherten Prozeduren werden Prozedurdefinition und -körper jeder Prozedur validiert, wenn sie in das neue Datenwörterbuch aufgenommen werden.

Vor MySQL 8 war es in einigen Fällen möglich, gespeicherte Routinen zu erstellen oder Prozeduren, die Sonderzeichen enthielten, direkt in die Tabelle mysql.proc einzufügen. Sie konnten beispielsweise eine gespeicherte Prozedur erstellen, die einen Kommentar mit dem nicht konformen, geschützten Leerzeichen \xa0 enthielt. Wenn solche Prozeduren gefunden werden, schlägt das Upgrade fehl.

Diese Vorabprüfung stellt sicher, dass die Körper und Definitionen Ihrer gespeicherten Prozeduren keine derartigen Zeichen enthalten. Damit das Upgrade fortgesetzt werden kann, müssen Sie diese gespeicherten Prozeduren ohne versteckte Zeichen oder Sonderzeichen neu erstellen.

Beispielausgabe:

{
  "id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
  "title": "Check for inconsistency related to special characters in stored procedures.",
  "status": "OK",
  "description": "Following procedure(s) has special characters inconsistency.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "information_schema.routines",
        "description": "Data Dictionary Metadata is inconsistent for the procedure `get_version_proc` in the database `test` due to usage of special characters in procedure body. To avoid that, drop and recreate the procedure without any special characters before proceeding with the Upgrade."
      }
  ]
}

Die Vorabprüfung meldet, dass der DB-Cluster eine Prozedur namens get_version_proc in der test-Datenbank enthält, deren Prozedurkörper Sonderzeichen enthält.

Nach dem Löschen und Neuerstellen der gespeicherten Prozedur ist die Vorabprüfung erfolgreich, sodass das Upgrade fortgesetzt werden kann.

{
  "id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
  "title": "Check for inconsistency related to special characters in stored procedures.",
  "status": "OK",
  "detectedProblems": []
},

Stufe der Vorabprüfung: Fehler

Prüfen der Nichtübereinstimmung von Objekttypen im sys-Schema

Das sys-Schema besteht aus einer Reihe von Objekten und Ansichten in einer MySQL-Datenbank und unterstützt Benutzer bei der Fehleranalyse, Optimierung und Überwachung ihrer DB-Instances. Wenn ein Hauptversions-Upgrade von Aurora-MySQL-Version 2 auf Version 3 durchgeführt wird, werden die sys-Schemaansichten neu erstellt und auf die neuen Definitionen von Aurora-MySQL-Version 3 aktualisiert.

Im Rahmen des Upgrades schlägt dieses fehl, wenn Objekte im sys-Schema mit Speicher-Engines (sys_config/BASE TABLE in INFORMATION_SCHEMA.TABLES) statt mit Ansichten definiert sind. Solche Tabellen finden Sie in der Tabelle information_schema.tables. Dies ist kein erwartetes Verhalten, kann aber in einigen Fällen aufgrund eines Benutzerfehlers auftreten.

Diese Vorabprüfung validiert alle sys-Schemaobjekte, um sicherzustellen, dass sie die richtigen Tabellendefinitionen verwenden und dass Ansichten nicht fälschlicherweise als InnoDB- oder MyISAM-Tabellen definiert sind. Zum Beheben des Problems korrigieren Sie alle zurückgegebenen Objekte manuell, indem Sie sie umbenennen oder löschen. Versuchen Sie anschließend das Upgrade erneut.

Beispielausgabe:

{
  "id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
  "title": "Check object type mismatch for sys schema.",
  "status": "OK",
  "description": "Database contains objects with type mismatch for sys schema.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "sys.waits_global_by_latency",
        "description": "Your object sys.waits_global_by_latency has a type mismatch. To fix the inconsistency we recommend to rename or remove the object before upgrading (use RENAME TABLE command). "
      }
  ]
}

Die Vorabprüfung meldet, dass die Ansicht sys.waits_global_by_latency im sys-Schema einen Typkonflikt aufweist, der die Fortsetzung des Upgrades verhindert.

Nachdem Sie sich bei der DB-Instance angemeldet haben, können Sie sehen, dass dieses Objekt als InnoDB-Tabelle definiert ist, obwohl es eine Ansicht sein sollte.

mysql> show create table sys.waits_global_by_latency\G
*************************** 1. row ***************************
       Table: waits_global_by_latency
Create Table: CREATE TABLE `waits_global_by_latency` (
  `events` varchar(128) DEFAULT NULL,
  `total` bigint(20) unsigned DEFAULT NULL,
  `total_latency` text,
  `avg_latency` text,
  `max_latency` text
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

Zum Beheben dieses Problems können wir die Ansicht entweder löschen und mit der richtigen Definition neu erstellen oder sie umbenennen. Während des Upgrade-Vorgangs wird sie automatisch mit der richtigen Tabellendefinition erstellt.

mysql> RENAME TABLE sys.waits_global_by_latency to sys.waits_global_by_latency_old;
Query OK, 0 rows affected (0.01 sec)

Nachdem dies durchgeführt wurde, ist die Vorabprüfung erfolgreich.

{
  "id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
  "title": "Check object type mismatch for sys schema.",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Prüfen der Obergrenze für einen Spaltennamen in einer Ansicht

Die maximal zulässige Länge eines Spaltennamens in MySQL beträgt 64 Zeichen. Vor MySQL 8.0 war es in einigen Fällen möglich, eine Ansicht mit einem Spaltennamen mit mehr als 64 Zeichen zu erstellen. Wenn solche Ansichten in Ihrer Datenbank-Instance existieren, wird ein Fehler bei der Vorabprüfung zurückgegeben und das Upgrade schlägt fehl. Damit das Upgrade fortgesetzt werden kann, müssen Sie die fraglichen Ansichten neu erstellen und dabei sicherstellen, dass ihre Spaltenlänge weniger als 64 Zeichen beträgt. Versuchen Sie anschließend das Upgrade erneut.

Beispielausgabe:

{
  "id": "auroraUpgradeCheckForViewColumnNameLength",
  "title": "Check for upperbound limit related to column name in view.",
  "status": "OK",
  "description": "Following view(s) has column(s) with length greater than 64.",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.colname_view_test.col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad",
        "description": "View `test`.`colname_view_test`has column `col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad` with invalid column name length. To avoid Upgrade errors, view should be altered by renaming the column name so that its length is not 0 and doesn't exceed 64."
      }
  ]
}

Die Vorabprüfung meldet, dass die Ansicht test.colname_view_test eine col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad-Spalte enthält, die die maximal zulässige Spaltenlänge von 64 Zeichen überschreitet.

Wenn wir uns die Ansichtsdefinition ansehen, können wir die problematische Spalte sehen.

mysql> desc `test`.`colname_view_test`;
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| Field                                                            | Type        | Null | Key | Default | Extra |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| col1                                                             | varchar(20) | YES  |     | NULL    |       |
| col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad | int(11)     | YES  |     | NULL    |       |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

Damit das Upgrade fortgesetzt werden kann, müssen Sie die Ansicht neu erstellen und dabei sicherstellen, dass die Spaltenlänge 64 Zeichen nicht überschreitet.

mysql> drop view `test`.`colname_view_test`;
Query OK, 0 rows affected (0.01 sec)

mysql> create view `test`.`colname_view_test`(col1, col2_nopad) as select inf, fodcol from test;
Query OK, 0 rows affected (0.01 sec)

mysql> desc `test`.`colname_view_test`;
+------------+-------------+------+-----+---------+-------+
| Field      | Type        | Null | Key | Default | Extra |
+------------+-------------+------+-----+---------+-------+
| col1       | varchar(20) | YES  |     | NULL    |       |
| col2_nopad | int(11)     | YES  |     | NULL    |       |
+------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

Nachdem dies durchgeführt wurde, ist die Vorabprüfung erfolgreich.

{
  "id": "auroraUpgradeCheckForViewColumnNameLength",
  "title": "Check for upperbound limit related to column name in view.",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Prüfen auf Tabellen mit Indizes, die für kleine Spalten mit einer Präfixlänge von mehr als 255 Byte definiert sind

Wenn Sie einen Index für eine Spalte mit einem binären Datentyp in MySQL erstellen, müssen Sie der Indexdefinition eine Präfixlänge hinzufügen. Vor MySQL 8.0 war es in einigen Fällen möglich, eine Präfixlänge anzugeben, die größer als die maximal zulässige Größe solcher Datentypen war. Ein Beispiel dafür sind TINYTEXT- und TINYBLOB-Spalten, bei denen die maximal zulässige Datengröße 255 Byte beträgt, aber auch größere Indexpräfixe zulässig waren. Weitere Informationen finden Sie unter Limits für InnoDB in der MySQL-Dokumentation.

Wenn diese Vorabprüfung fehlschlägt, löschen Sie den problematischen Index oder reduzieren Sie die Präfixlänge von TINYTEXT- und TINYBLOB-Spalten des Indexes auf weniger als 255 Byte. Versuchen Sie anschließend das Upgrade erneut.

Beispielausgabe:

{
  "id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
  "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
  "status": "OK",
  "description": "Prefix length of the indexes defined on tiny columns cannot exceed 255 bytes. With utf8mb4 char set, this limits the prefix length supported upto 63 characters only. A larger prefix length was allowed in MySQL5.7 using innodb_large_prefix parameter. This parameter is deprecated in MySQL 8.0.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html, https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.tintxt_prefixed_index.col1",
        "description": "Index 'PRIMARY' on tinytext/tinyblob column `col1` of table `test.tintxt_prefixed_index` is defined with prefix length exceeding 255 bytes. Reduce the prefix length to <=255 bytes depending on character set used. For utf8mb4, it should be <=63."
      }
  ]
}

Die Vorabprüfung meldet einen Fehler für die Tabelle test.tintxt_prefixed_index, da sie über einen PRIMARY-Index verfügt, dessen Präfix für eine TINYTEXT- oder TINYBLOB-Spalte größer als 255 Byte ist.

Wenn wir uns die Definition für diese Tabelle ansehen, können wir sehen, dass der Primärschlüssel einen Präfix von 65 für die TINYTEXT-Spalte col1 aufweist. Da die Tabelle mit dem utf8mb4-Zeichensatz definiert wird, der 4 Byte pro Zeichen speichert, überschreitet das Präfix die 255-Byte-Grenze.

mysql> show create table `test`.`tintxt_prefixed_index`\G
*************************** 1. row ***************************
       Table: tintxt_prefixed_index
Create Table: CREATE TABLE `tintxt_prefixed_index` (
  `col1` tinytext NOT NULL,
  `col2` tinytext,
  `col_id` tinytext,
  PRIMARY KEY (`col1`(65))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC
1 row in set (0.00 sec)

Wenn Sie das Indexpräfix auf 63 ändern, während Sie den utf8mb4-Zeichensatz verwenden, kann das Upgrade fortgesetzt werden.

mysql> alter table `test`.`tintxt_prefixed_index` drop PRIMARY KEY, ADD  PRIMARY KEY (`col1`(63));
Query OK, 0 rows affected (0.04 sec)
Records: 0  Duplicates: 0  Warnings: 0

Nachdem dies durchgeführt wurde, ist die Vorabprüfung erfolgreich.

{
  "id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
  "title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Fehler

Prüfen der Inkonsistenz fehlender InnoDB-Metadaten für die Tabelle mysql.host

Dies ist eine rein interne Vorabprüfung, die vom RDS-Service durchgeführt wird. Alle Fehler werden beim Upgrade automatisch behandelt und können problemlos ignoriert werden.

Wenn Sie bei dieser Vorabprüfung auf Fehler stoßen, wenden Sie sich an den AWS Support, um die Behebung der Metadaten-Inkonsistenz zu beantragen. Alternativ können Sie das Upgrade erneut versuchen, indem Sie einen logischen Dump durchführen und dann in einem neuen DB-Cluster von Aurora-MySQL-Version 3 wiederherstellen.

Stufe der Vorabprüfung: Warnung

Überlegungen zum neuen Standard-Authentifizierungs-Plugin

In MySQL 8.0 wurde das caching_sha2_password-Authentifizierungs-Plugin eingeführt, das eine sicherere Passwortverschlüsselung und eine bessere Leistung als das veraltete mysql_native_password-Plugin bietet. Für Aurora-MySQL-Version 3 ist das für Datenbankbenutzer verwendete Standard-Authentifizierungs-Plugin das mysql_native_password-Plugin.

Diese Vorabprüfung warnt davor, dass dieses Plugin entfernt und die Standardeinstellung in einer künftigen Hauptversion geändert wird. Erwägen Sie, vor dieser Änderung die Kompatibilität Ihrer Anwendungsclients und Benutzer zu überprüfen.

Weitere Informationen finden Sie unter Kompatibilitätsprobleme mit caching_sha2_password und deren Lösungen in der MySQL-Dokumentation.

Beispielausgabe:

{
  "id": "defaultAuthenticationPlugin",
  "title": "New default authentication plugin considerations",
  "description": "Warning: The new default authentication plugin 'caching_sha2_password' offers more secure password hashing than previously used 'mysql_native_password' (and consequent improved client connection authentication). However, it also has compatibility implications that may affect existing MySQL installations. If your MySQL installation must serve pre-8.0 clients and you encounter compatibility issues after upgrading, the simplest way to address those issues is to reconfigure the server to revert to the previous default authentication plugin (mysql_native_password). For example, use these lines in the server option file:\n\n[mysqld]\ndefault_authentication_plugin=mysql_native_password\n\nHowever, the setting should be viewed as temporary, not as a long term or permanent solution, because it causes new accounts created with the setting in effect to forego the improved authentication security.\nIf you are using replication please take time to understand how the authentication plugin changes may impact you.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues\nhttps://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication"
},

Stufe der Vorabprüfung: Warnung

Verwendung eines veralteten MAXDB-sql_mode-Flags

In MySQL 8.0 wurden eine Reihe von veralteten sql_mode-Systemvariablenoptionen entfernt, darunter MAXDB. Diese Vorabprüfung untersucht alle derzeit verbundenen Sitzungen sowie Routinen und Trigger, um sicherzustellen, dass keine davon sql_mode auf eine Kombination gesetzt haben, die MAXDB enthält.

Beispielausgabe:

{
  "id": "maxdbFlagCheck",
  "title": "Usage of obsolete MAXDB sql_mode flag",
  "status": "OK",
  "description": "Warning: The following DB objects have the obsolete MAXDB option persisted for sql_mode, which will be cleared during the upgrade. It can potentially change the datatype DATETIME into TIMESTAMP if it is used inside object's definition, and this in turn can change the behavior in case of dates earlier than 1970 or later than 2037. If this is a concern, please redefine these objects so that they do not rely on the MAXDB flag before running the upgrade.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.maxdb_stored_routine",
        "description": "PROCEDURE uses obsolete MAXDB sql_mode",
        "dbObjectType": "Routine"
      }
  ]
}

Die Vorabprüfung meldet, dass die Routine test.maxdb_stored_routine eine nicht unterstützte sql_mode-Option enthält.

Nachdem Sie sich bei der Datenbank angemeldet haben, können Sie in der Routinedefinition sehen, dass sql_mode MAXDB enthält.

 > SHOW CREATE PROCEDURE test.maxdb_stored_routine\G

*************************** 1. row ***************************
           Procedure: maxdb_stored_routine
            sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,MAXDB,NO_KEY_OPTIONS,NO_TABLE_OPTIONS,NO_FIELD_OPTIONS,NO_AUTO_CREATE_USER
    Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
    SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

Zum Beheben des Problems erstellen Sie die Prozedur neu, nachdem Sie den richtigen sql_mode auf dem Client festgelegt haben.

Erstellen Sie die Prozedur ohne den nicht unterstützten sql_mode neu.

mysql > set sql_mode='PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE';
Query OK, 0 rows affected, 1 warning (0.00 sec)

mysql > DROP PROCEDURE test.maxdb_stored_routine\G
Query OK, 0 rows affected (0.00 sec)

mysql >
mysql > DELIMITER $$
mysql >
mysql > CREATE PROCEDURE test.maxdb_stored_routine()
    -> SQL SECURITY DEFINER
    -> BEGIN
    ->     SELECT * FROM test;
    -> END$$
Query OK, 0 rows affected (0.00 sec)

mysql >
mysql > DELIMITER ;
mysql > show create procedure test.maxdb_stored_routine\G
*************************** 1. row ***************************
           Procedure: maxdb_stored_routine
            sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE
    Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
    SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
  Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)

Die Vorabprüfung ist erfolgreich.

{
  "id": "maxdbFlagCheck",
  "title": "Usage of obsolete MAXDB sql_mode flag",
  "status": "OK",
  "detectedProblems": []
}

Stufe der Vorabprüfung: Warnung

Prüfen auf die veraltete Verwendung einzelner Dollarzeichen in Objektnamen

Ab MySQL 8.0.32 ist die Verwendung des Dollarzeichens ($) als erstes Zeichen eines Bezeichners ohne Anführungszeichen veraltet. Wenn Sie über Schemas, Tabellen, Ansichten, Spalten oder Routinen verfügen, die ein $ als erstes Zeichen enthalten, gibt diese Vorabprüfung eine Warnung zurück. Diese Warnung verhindert zwar nicht, dass das Upgrade fortgesetzt wird, wir empfehlen Ihnen jedoch, bald Maßnahmen zu ergreifen, um dieses Problem zu beheben. Ab MySQL 8.4 geben solche Bezeichner eher einen Syntaxfehler als eine Warnung zurück.

Beispielausgabe:

{
  "id": "mysqlDollarSignNameCheck",
  "title": "Check for deprecated usage of single dollar signs in object names",
  "status": "OK",
  "description": "Warning: The following objects have names with deprecated usage of dollar sign ($) at the begining of the identifier. To correct this warning, ensure, that names starting with dollar sign, also end with it, similary to quotes ($example$). ",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.$deprecated_syntx",
        "description": " name starts with $ sign."
      }
  ]
},

Die Vorabprüfung gibt eine Warnung aus, da die Tabelle $deprecated_syntx im test-Schema ein $ als erstes Zeichen enthält.

Stufe der Vorabprüfung: Warnung

Verwendung von Datenbankobjekten, deren Namen mit neuen reservierten Schlüsselwörtern kollidieren

Diese Prüfung ähnelt routineSyntaxCheck, da sie die Verwendung von Datenbankobjekten prüft, deren Namen mit neuen reservierten Schlüsselwörtern kollidieren. Obwohl sie Upgrades nicht blockieren, müssen Warnungen sorgfältig bewertet werden.

Beispielausgabe:

Bei Verwendung des vorherigen Beispiels mit der Tabelle namens except gibt die Vorabprüfung eine Warnung zurück:

{
  "id": "reservedKeywordsCheck",
  "title": "Usage of db objects with names conflicting with new reserved keywords",
  "status": "OK",
  "description": "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.",
  "documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.except",
        "description": "Table name",
        "dbObjectType": "Table"
      }
  ]
}

Diese Warnung informiert Sie darüber, dass möglicherweise einige Anwendungsabfragen überprüft werden müssen. Wenn Ihre Anwendungsabfragen Zeichenfolgenliterale nicht korrekt maskieren, kann es nach dem Upgrade auf MySQL 8.0 zu Fehlern kommen. Überprüfen Sie Ihre Anwendungen zur Bestätigung und testen Sie sie anhand eines Klons oder Snapshots Ihres DB-Clusters von Aurora MySQL, der auf Version 3 ausgeführt wird.

Beispiel für eine nicht maskierte Anwendungsabfrage, die nach dem Upgrade fehlschlägt:

SELECT * FROM escape;

Beispiel für eine korrekt maskierte Anwendungsabfrage, die nach dem Upgrade erfolgreich ist:

SELECT * FROM 'escape';

Stufe der Vorabprüfung: Warnung

Verwendung des utf8mb3-Zeichensatzes

In MySQL 8.0 ist der utf8mb3-Zeichensatz veraltet und wird in einer künftigen MySQL-Hauptversion entfernt. Diese Vorabprüfung ist implementiert, um eine Warnung auszulösen, wenn Datenbankobjekte mit diesem Zeichensatz erkannt werden. Dies verhindert zwar nicht, dass ein Upgrade fortgesetzt wird, wir empfehlen Ihnen jedoch dringend, darüber nachzudenken, Tabellen zum utf8mb4-Zeichensatz zu migrieren, der ab MySQL 8.0 die Standardeinstellung ist. Weitere Informationen zu utf8mb3 und utf8mb4 finden Sie unter Konvertierung zwischen 3-Byte- und 4-Byte-Unicode-Zeichensätzen in der MySQL-Dokumentation.

Beispielausgabe:

{
  "id": "utf8mb3",
  "title": "Usage of utf8mb3 charset",
  "status": "OK",
  "description": "Warning: The following objects use the deprecated utf8mb3 character set. It is recommended to convert them to use utf8mb4 instead, for improved Unicode support. The utf8mb3 character is subject to removal in the future.",
  "documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.t1.col1",
        "description": "column's default character set: utf8",
        "dbObjectType": "Column"
      },
      {
        "level": "Warning",
        "dbObject": "test.t1.col2",
        "description": "column's default character set: utf8",
        "dbObjectType": "Column"
      }
  ]
}

Zum Beheben dieses Problems erstellen Sie die Objekte und Tabellen neu, auf die verwiesen wird. Weitere Informationen und Voraussetzungen dafür finden Sie unter Konvertierung zwischen 3-Byte- und 4-Byte-Unicode-Zeichensätzen in der MySQL-Dokumentation.

Stufe der Vorabprüfung: Warnung

Nullwerte für Date, Datetime und Timestamp

MySQL erzwingt jetzt strengere Regeln für die Verwendung von Nullwerten in Date-, Datetime- und Timestamp-Spalten. Wir empfehlen, die Modi NO_ZERO_IN_DATE und NO_ZERO_DATE SQL zusammen mit dem Modus strict zu verwenden, da sie in einer künftigen MySQL-Version mit dem Modus strict zusammengeführt werden.

Wenn die sql_mode-Einstellung für eine Ihrer Datenbankverbindungen zum Zeitpunkt der Ausführung der Vorabprüfung diese Modi nicht enthält, wird bei der Vorabprüfung eine Warnung ausgegeben. Benutzer können möglicherweise weiterhin Werte für Date, Datetime und Timestamp einfügen, die Nullwerte enthalten. Wir empfehlen jedoch dringend, alle Nullwerte durch gültige Werte zu ersetzen, da sich ihr Verhalten in Zukunft ändern könnte und sie möglicherweise nicht richtig funktionieren. Da es sich um eine Warnung handelt, werden Upgrades dadurch nicht blockiert. Wir empfehlen Ihnen jedoch, mit der Planung von Maßnahmen zu beginnen.

Beispielausgabe:

{
  "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"
      }
  ]
}

Stufe der Vorabprüfung: Warnung

Prüft, ob die Länge der Liste des Rollback-Segmentverlaufs für den Cluster hoch ist

Wie in auroraUpgradeCheckForIncompleteXATransactions erwähnt, ist es wichtig, dass die DB-Instance von Aurora-MySQL-Version 2 während des Upgrade-Prozesses für die Hauptversion ordnungsgemäß heruntergefahren wird. Dadurch wird sichergestellt, dass alle Transaktionen festgeschrieben oder rückgängig gemacht werden und dass InnoDB alle Undo-Protokolleinträge bereinigt hat.

Wenn Ihr DB-Cluster eine hohe Länge der Liste des Rollback-Segmentverlaufs (History List Length, HLL) aufweist, kann das die Zeit verlängern, die InnoDB benötigt, um die Undo-Protokolleinträge zu bereinigen. Dies führt zu längeren Ausfallzeiten während des Upgrade-Prozesses für die Hauptversion. Wenn die Vorabprüfung feststellt, dass der HLL-Wert in Ihrem DB-Cluster hoch ist, wird eine Warnung ausgegeben. Dies verhindert zwar nicht, dass Ihr Upgrade fortgesetzt wird, wir empfehlen Ihnen jedoch, die HLL in Ihrem DB-Cluster genau zu überwachen. Ein möglichst niedriger Wert reduziert die Ausfallzeit, die während des Hauptversions-Upgrade erforderlich ist. Weitere Informationen zur Überwachung der HLL finden Sie unter Die Länge der InnoDB-Verlaufsliste wurde deutlich erhöht.

Beispielausgabe:

{
  "id": "auroraUpgradeCheckForRollbackSegmentHistoryLength",
  "title": "Checks if the rollback segment history length for the cluster is high",
  "status": "OK",
  "description": "Rollback Segment History length is greater than 1M. Upgrade may take longer time.",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "information_schema.innodb_metrics",
        "description": "The InnoDB undo history list length('trx_rseg_history_len') is 82989114. Upgrade may take longer due to purging of undo information for old row versions."
      }
  ]
}

Die Vorabprüfung gibt eine Warnung zurück, da festgestellt wurde, dass die InnoDB-Undo-HLL im Datenbank-Cluster hoch war (82989114). Obwohl das Upgrade fortgesetzt wird, kann sich die erforderliche Ausfallzeit während des Upgrade-Vorgangs je nach Umfang der zu bereinigenden Undo-Daten verlängern.

Wir empfehlen Ihnen, offene Transaktionen in Ihrem DB-Cluster zu untersuchen, bevor Sie das Upgrade in der Produktion ausführen, um sicherzustellen, dass Ihre HLL eine überschaubare Größe hat.

Stufe der Vorabprüfung: Warnung

Prüft, ob es viele nicht festgeschriebene Zeilenänderungen gibt

Wie in auroraUpgradeCheckForIncompleteXATransactions erwähnt, ist es wichtig, dass die DB-Instance von Aurora-MySQL-Version 2 während des Upgrade-Prozesses für die Hauptversion ordnungsgemäß heruntergefahren wird. Dadurch wird sichergestellt, dass alle Transaktionen festgeschrieben oder rückgängig gemacht werden und dass InnoDB alle Undo-Protokolleinträge bereinigt hat.

Wenn Ihr DB-Cluster über Transaktionen verfügt, die eine große Anzahl von Zeilen geändert haben, kann dies die Zeit verlängern, die InnoDB benötigt, um ein Rollback dieser Transaktion als Teil des ordnungsgemäßen Herunterfahrens abzuschließen. Wenn bei der Vorabprüfung lang laufende Transaktionen mit einer großen Anzahl von geänderten Zeilen in Ihrem DB-Cluster festgestellt werden, wird eine Warnung ausgegeben. Dies verhindert zwar nicht, dass Ihr Upgrade fortgesetzt wird, wir empfehlen Ihnen jedoch, die Größe der aktiven Transaktionen in Ihrem DB-Cluster genau zu überwachen. Ein möglichst niedriger Wert reduziert die Ausfallzeit, die während des Hauptversions-Upgrade erforderlich ist.

Beispielausgabe:

{
  "id": "auroraUpgradeCheckForUncommittedRowModifications",
  "title": "Checks if there are many uncommitted modifications to rows",
  "status": "OK",
  "description": "Database contains uncommitted row changes greater than 10M. Upgrade may take longer time.",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "information_schema.innodb_trx",
        "description": "The database contains 11000000 uncommitted row change(s) in 1 transaction(s). Upgrade may take longer due to transaction rollback."
      }
  ]
},

Die Vorabprüfung meldet, dass der DB-Cluster eine Transaktion mit 11 000 000 nicht festgeschriebenen Zeilenänderungen enthält, die während des ordnungsgemäßen Herunterfahrens rückgängig gemacht werden müssen. Das Upgrade wird fortgesetzt, aber um die Ausfallzeiten während des Upgrade-Prozesses zu reduzieren, empfehlen wir Ihnen, dies zu überwachen und zu untersuchen, bevor Sie das Upgrade in Ihren Produktions-Clustern ausführen.

Wenn Sie aktive Transaktionen in Ihrer Schreiber-DB-Instance anzeigen möchten, können Sie die Tabelle information_schema.innodb_trx verwenden. Die folgende Abfrage der Schreiber-DB-Instance zeigt aktuelle Transaktionen, die Laufzeit, den Status und geänderte Zeilen für den DB-Cluster.

# Example of uncommitted transaction
mysql> SELECT trx_started,
       TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
       trx_mysql_thread_id AS show_processlist_connection_id,
       trx_id,
       trx_state,
       trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| trx_started         | seconds_trx_has_been_running | show_processlist_connection_id | trx_id   | trx_state | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| 2024-08-12 18:32:52 |                         1592 |                          20041 | 52866130 | RUNNING   |      11000000 |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
1 row in set (0.01 sec)

# Example of transaction rolling back
mysql> SELECT trx_started,
       TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
       trx_mysql_thread_id AS show_processlist_connection_id,
       trx_id,
       trx_state,
       trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| trx_started         | seconds_trx_has_been_running | show_processlist_connection_id | trx_id   | trx_state    | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| 2024-08-12 18:32:52 |                         1719 |                          20041 | 52866130 | ROLLING BACK |      10680479 |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
1 row in set (0.01 sec)

Nachdem die Transaktion festgeschrieben oder rückgängig gemacht wurde, gibt die Vorabprüfung keine Warnung mehr zurück. Konsultieren Sie die MySQL-Dokumentation und Ihr Anwendungsteam, bevor Sie große Transaktionen rückgängig machen, da das Rollback je nach Transaktionsgröße einige Zeit in Anspruch nehmen kann.

{
  "id": "auroraUpgradeCheckForUncommittedRowModifications",
  "title": "Checks if there are many uncommitted modifications to rows",
  "status": "OK",
  "detectedProblems": []
},

Weitere Informationen zur Optimierung der InnoDB-Transaktionsverwaltung und zu den möglichen Auswirkungen der Ausführung und des Rollbacks großer Transaktionen in MySQL-Datenbank-Instances finden Sie unter Optimieren der InnoDB-Transaktionsverwaltung in der MySQL-Dokumentation.

Stufe der Vorabprüfung: Hinweis

Verwendung von veralteten sql_mode-Flags

Zusätzlich zu MAXDB wurden eine Reihe weiterer sql_mode-Optionen entfernt: DB2, MSSQL, MYSQL323, MYSQL40, ORACLE, POSTGRESQL, NO_FIELD_OPTIONS, NO_KEY_OPTIONS und NO_TABLE_OPTIONS. Ab MySQL 8.0 kann keiner dieser Werte der Systemvariablen sql_mode zugewiesen werden. Wenn diese Vorabprüfung offene Sitzungen findet, die diese sql_mode-Einstellungen verwenden, stellen Sie sicher, dass Ihre DB-Instance- und DB-Cluster-Parametergruppen sowie Client-Anwendungen und -Konfigurationen aktualisiert werden, um sie zu deaktivieren. Weitere Informationen finden Sie in der MySQL-Dokumentation.

Beispielausgabe:

{
  "id": "sqlModeFlagCheck",
  "title": "Usage of obsolete sql_mode flags",
  "status": "OK",
  "detectedProblems": []
}

Informationen zum Beheben dieser Fehler bei der Vorabprüfung finden Sie unter maxdbFlagCheck.

Stufe der Vorabprüfung: Fehler, Warnung oder Hinweis

Probleme, die vom Befehl check table x for upgrade gemeldet wurden

Bevor das Upgrade auf Aurora-MySQL-Version 3 gestartet wird, wird check table for upgrade für jede Tabelle in den Benutzerschemas in Ihrem DB-Cluster ausgeführt. Diese Vorabprüfung entspricht nicht checkTableMysqlSchema.

Der Befehl check table for upgrade untersucht Tabellen auf mögliche Probleme, die bei einem Upgrade auf eine neuere Version von MySQL auftreten könnten. Das Ausführen dieses Befehls vor dem Upgrade kann helfen, etwaige Inkompatibilitäten im Voraus zu identifizieren und zu beheben, sodass der eigentliche Upgrade-Prozess reibungsloser abläuft.

Mit diesem Befehl werden verschiedene Prüfungen für jede Tabelle durchgeführt, z. B. die folgenden:

Im Gegensatz zu anderen Vorabprüfungen kann sie je nach check table-Ausgabe einen Fehler, eine Warnung oder einen Hinweis zurückgeben. Wenn diese Vorabprüfung Tabellen zurückgibt, überprüfen Sie diese zusammen mit dem Rückgabecode und der Meldung sorgfältig, bevor Sie das Upgrade starten. Weitere Informationen finden Sie unter CHECK-TABLE-Anweisung in der MySQL-Dokumentation.

Hier finden Sie ein Beispiel für einen Fehler und eine Warnung.

Beispiel für einen Fehler:

{
  "id": "checkTableOutput",
  "title": "Issues reported by 'check table x for upgrade' command",
  "status": "OK",
  "detectedProblems": [
      {
        "level": "Error",
        "dbObject": "test.parent",
        "description": "Table 'test.parent' doesn't exist"
      }
  ]
},

Die Vorabprüfung meldet einen Fehler, der besagt, dass die Tabelle test.parent nicht existiert.

Die mysql-error.log-Datei für die Schreiber-DB-Instance zeigt, dass ein Fremdschlüsselfehler vorliegt.

2024-08-13T15:32:10.676893Z 62 [Warning] InnoDB: Load table `test`.`parent` failed, the table has missing foreign key indexes. Turn off 'foreign_key_checks' and try again.
2024-08-13T15:32:10.676905Z 62 [Warning] InnoDB: Cannot open table test/parent from the internal data dictionary of InnoDB though the .frm file for the table exists.
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.

Melden Sie sich bei der Schreiber-DB-Instance an und führen Sie show engine innodb status\G aus, um weitere Informationen zum Fremdschlüsselfehler zu erhalten.

mysql> show engine innodb status\G
*************************** 1. row ***************************
  Type: InnoDB
  Name:
Status:
=====================================
2024-08-13 15:33:33 0x14ef7b8a1700 INNODB MONITOR OUTPUT
=====================================
.
.
.
------------------------
LATEST FOREIGN KEY ERROR
------------------------
2024-08-13 15:32:10 0x14ef6dbbb700 Error in foreign key constraint of table test/child:
there is no index in referenced table which would contain
the columns as the first columns, or the data types in the
referenced table do not match the ones in table. Constraint:
,
  CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
The index in the foreign key in table is p_name_idx
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-foreign-key-constraints.html for correct foreign key definition.
.
.

Die LATEST FOREIGN KEY ERROR-Meldung gibt an, dass die fk_pname-Fremdschlüsseleinschränkung in der Tabelle test.child, die auf die Tabelle test.parent verweist, entweder einen fehlenden Index oder einen Datentypkonflikt aufweist. Die MySQL-Dokumentation zu Fremdschlüsseleinschränkungen besagt, dass Spalten, auf die in einem Fremdschlüssel verwiesen wird, einen zugehörigen Index haben müssen und dass die übergeordneten/untergeordneten Spalten denselben Datentyp verwenden müssen.

Wenn Sie überprüfen möchten, ob dies mit einem fehlenden Index oder einer Nichtübereinstimmung des Datentyps zusammenhängt, melden Sie sich bei der Datenbank an und überprüfen Sie die Tabellendefinitionen, indem Sie vorübergehend die Sitzungsvariable foreign_key_checks deaktivieren. Danach können wir sehen, dass die fragliche untergeordnete Einschränkung (fk_pname) p_name varchar(20) CHARACTER SET latin1 DEFAULT NULL verwendet, um auf die übergeordnete Tabelle name varchar(20) NOT NULL zu verweisen. Die übergeordnete Tabelle verwendet DEFAULT CHARSET=utf8, aber die Spalte p_name der untergeordneten Tabelle verwendet latin1, sodass der Fehler wegen fehlender Datentypübereinstimmung ausgelöst wird.

mysql> show create table parent\G
ERROR 1146 (42S02): Table 'test.parent' doesn't exist

mysql> show create table child\G
*************************** 1. row ***************************
       Table: child
Create Table: CREATE TABLE `child` (
  `id` int(11) NOT NULL,
  `p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `p_name_idx` (`p_name`),
  CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

mysql> set foreign_key_checks=0;
Query OK, 0 rows affected (0.00 sec)

mysql> show create table parent\G
*************************** 1. row ***************************
       Table: parent
Create Table: CREATE TABLE `parent` (
  `name` varchar(20) NOT NULL,
  PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

mysql> show create table child\G
*************************** 1. row ***************************
       Table: child
Create Table: CREATE TABLE `child` (
  `id` int(11) NOT NULL,
  `p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `p_name_idx` (`p_name`),
  CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

Zum Beheben dieses Problems können wir entweder die untergeordnete Tabelle so ändern, dass sie denselben Zeichensatz wie die übergeordnete Tabelle verwendet, oder die übergeordnete Tabelle so ändern, dass sie denselben Zeichensatz wie die untergeordnete Tabelle verwendet. Da die untergeordnete Tabelle hier explizit latin1 in der p_name-Spaltendefinition verwendet, führen wir ALTER TABLE aus, um den Zeichensatz in utf8 zu ändern.

mysql> alter table child modify p_name varchar(20) character set utf8 DEFAULT NULL;
Query OK, 0 rows affected (0.06 sec)
Records: 0  Duplicates: 0  Warnings: 0

mysql> flush tables;
Query OK, 0 rows affected (0.01 sec)

Danach ist die Vorabprüfung erfolgreich und das Upgrade kann fortgesetzt werden.

Beispiel für eine Warnung:

{
  "id": "checkTableOutput",
  "title": "Issues reported by 'check table x for upgrade' command",
  "status": "OK",
  "detectedProblems": [
      {
        "level": "Warning",
        "dbObject": "test.orders",
        "description": "Trigger test.orders.delete_audit_trigg does not have CREATED attribute."
      }
  ]
}

Die Vorabprüfung meldet eine Warnung für den Trigger delete_audit_trigg in der Tabelle test.orders, da er kein CREATED-Attribut aufweist. Laut Überprüfen der Versionskompatibilität in der MySQL-Dokumentation ist diese Meldung informativ und wird für Trigger angezeigt, die vor MySQL 5.7.2 erstellt wurden.

Da es sich um eine Warnung handelt, verhindert sie nicht, dass das Upgrade fortgesetzt wird. Wenn Sie das Problem jedoch beheben möchten, können Sie den fraglichen Trigger neu erstellen und die Vorabprüfung ist ohne Warnungen erfolgreich.

{
  "id": "checkTableOutput",
  "title": "Issues reported by 'check table x for upgrade' command",
  "status": "OK",
  "detectedProblems": []
},