Referenz für Precheck-Beschreibungen für Aurora My SQL

Stufe der Vorabprüfung: Fehler

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

Bevor das Upgrade auf Aurora My SQL Version 3 gestartet check table for upgrade wird, wird es für jede Tabelle im mysql Schema auf der DB-Instance ausgeführt. Der check table for upgrade Befehl untersucht Tabellen auf mögliche Probleme, die während eines Upgrades auf eine neuere Version von My auftreten könntenSQL. Wenn Sie diesen Befehl vor einem Upgrade ausführen, können Sie etwaige Inkompatibilitäten im Voraus identifizieren und beheben, sodass der eigentliche Upgradevorgang reibungsloser abläuft.

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

Weitere Informationen finden Sie in der CHECKTABLEErklärung unter Meine SQL Dokumentation.

Beispielausgabe:

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

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

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

Stufe der Vorabprüfung: Fehler

Zirkuläre Verzeichnisverweise in Tablespace-Datendateipfaden

Ab My SQL 8.0.17 erlaubt die CREATE TABLESPACE ... ADD DATAFILE Klausel keine zirkulären Verzeichnisverweise mehr. Um Upgrade-Probleme zu vermeiden, entfernen Sie alle zirkulären Verzeichnisverweise aus den Tablespace-Datendateipfaden, bevor Sie auf Aurora My SQL 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 mithilfe eines file-per-table Tablespace neu. Verwenden Sie Standarddateipfade für alle Tablespace- und Tabellendefinitionen.

Nach der Neuerstellung 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 können

Vor My SQL 8.0.13 können JSON SpaltenBLOB,TEXT,GEOMETRY, und keine Standardwerte haben. Entfernen Sie alle Standardklauseln in diesen Spalten, bevor Sie auf Aurora My SQL Version 3 aktualisieren. Weitere Informationen zu Änderungen an der Standardbehandlung für diese Datentypen finden Sie unter Standardwerte für Datentypen in der SQL Dokumentation Meine.

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 geo_col Spalte in der test.test_blob_default Tabelle einenBLOB, TEXTGEOMETRY, oder JSON -Datentyp mit einem angegebenen Standardwert verwendet.

Wenn wir uns die Tabellendefinition ansehen, können wir sehen, dass die geo_col Spalte definiert ist alsgeo_col geometry NOT NULL default ''.

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

Diese Standardklausel wird entfernt, damit die Vorabprüfung bestanden werden kann.

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 abgewerteten Schlüsselwörtern in der Definition

Mein SQL 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 SQL_NO_CACHE Schlüsselwörter, oder enthält QUERY CACHESQL_CACHE, wird ein Fehler bei der Vorabprüfung zurückgegeben. Um dieses Problem zu beheben, erstellen Sie diese Objekte neu und entfernen Sie dabei die genannten Schlüsselwörter.

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 test.no_query_cache_check gespeicherte Prozedur eines der entfernten Schlüsselwörter verwendet. Wenn wir uns die Prozedurdefinition ansehen, können wir sehen, dass sie verwendetSQL_NO_CACHE.

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 bei dieser Vorabprüfung wird überprüft schemaInconsistencyCheck, ob die Tabellenmetadaten in My konsistent SQL 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 Metadateninkonsistenz zu beantragen. Alternativ können Sie das Upgrade erneut versuchen, indem Sie einen logischen Speicherauszug durchführen und dann auf einem neuen Aurora My SQL Version 3-DB-Cluster 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

ENUMund SET Spaltendefinitionen, die Elemente enthalten, die länger als 255 Zeichen sind

Tabellen und gespeicherte Prozeduren dürfen keine ENUM oder keine SET Spaltenelemente haben, die 255 Zeichen oder 1020 Byte überschreiten. Vor My SQL 8.0 betrug die maximale kombinierte Länge 64 KB, aber 8.0 begrenzt einzelne Elemente auf 255 Zeichen oder 1020 Byte (unterstützt Multibyte). Wenn bei der Vorabprüfung ein Fehler auftrittenumSetElementLengthCheck, ä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 test.large_set Tabelle 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 vorprüfen: Fehler

Namen von Fremdschlüsseleinschränkungen, die länger als 64 Zeichen sind

In My SQL ist die Länge von Bezeichnern auf 64 Zeichen begrenzt, wie in der SQLDokumentation zu My 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 an der Implementierung des Datenwörterbuches unterstützt My SQL 8.0 in einer Datenbank keine Trigger, bei denen Groß- und Kleinschreibung beachtet wird. Diese Vorabprüfung bestätigt, dass Ihr DB-Cluster nicht über eine oder mehrere Datenbanken verfügt, die doppelte Trigger enthalten. Weitere Informationen finden Sie in der Dokumentation Meine SQL Dokumentation unter Berücksichtigung der Groß- und Kleinschreibung von Identifier.

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 der Fehler gemeldet, dass der Datenbank-Cluster zwei Trigger mit demselben Namen hat, aber unterschiedliche Groß- und Kleinschreibung verwenden: test.before_insert_product undtest.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 test.before_insert_PRODUCT in ist die test.before_insert_product_2 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 Definiererspalte für mysql.event darf weder Null noch leer sein.

Das DEFINER Attribut gibt die Definition „Mein SQL 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 steuern möchten, in dem das gespeicherte Objekt ausgeführt wird. Wenn beim Erstellen eines gespeicherten Objekts DEFINER kein a angegeben ist, wird standardmäßig der Benutzer verwendet, der das Objekt erstellt hat.

Wenn Sie auf My SQL 8.0 aktualisieren, können Sie keine gespeicherten Objekte mit einem null oder einem leeren Definer im My SQL Data Dictionary haben. Wenn Sie über solche gespeicherten Objekte verfügen, wird ein Fehler bei der Vorabprüfung ausgelöst. Sie müssen das Problem 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"
      }
  ]
}

Bei der Vorabprüfung wird ein Fehler für das test.get_version Ereignis zurückgegeben, da es einen null Definierer hat.

Um dieses Problem zu beheben, können Sie die Ereignisdefinition überprüfen. Wie Sie sehen können, ist der Definer leer 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": []},

Precheck-Stufe: Fehler

Diskrepanz der Spaltendefinition zwischen dem InnoDB-Datenwörterbuch und der tatsächlichen Tabellendefinition

Ähnlich wie bei dieser Vorabprüfung wird überprüft schemaInconsistencyCheck, ob die Tabellenmetadaten in My konsistent sind, bevor mit dem Upgrade fortgefahren SQL wird. In diesem Fall überprüft die Vorabprüfung, ob die Spaltendefinitionen zwischen dem InnoDB-Datenwörterbuch und der Definition Meine SQL Tabelle ü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 Metadateninkonsistenz zu beantragen. Alternativ können Sie das Upgrade erneut versuchen, indem Sie einen logischen Speicherauszug durchführen und dann auf einem neuen Aurora My SQL Version 3-DB-Cluster 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 der Metadaten für die id Spalte in der test.mismatchTable Tabelle gemeldet. Insbesondere haben die SQL Metadaten Meine Metadaten den Spaltennamen alsiD, während InnoDB ihn als id hat.

Stufe der Vorabprüfung: Fehler

Die Definiererspalte für information_schema.triggers darf nicht null oder leer sein.

Die Vorabprüfung bestätigt, dass in Ihrer Datenbank keine Trigger mit Definierern definiert sind null oder dass sie leer sind. Weitere Informationen zu den Defineranforderungen 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 example_trigger Trigger im test Schema einen null Definierer hat. Um dieses Problem zu beheben, korrigieren Sie den Definer, indem Sie den Trigger mit einem gültigen Benutzer neu erstellen, oder löschen Sie den Trigger. Weitere Informationen finden Sie im Beispiel unter. getEventsWithNullDefiner

Stufe der Vorabprüfung: Fehler

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

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

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

Weitere Informationen finden Sie unter Änderungen am Datenwörterbuch in der Dokumentation Meine. SQL

Um Probleme beim Upgrade bei der Aktualisierung dateibasierter Metadaten auf das neue Atomic Data Dictionary zu vermeiden, überprüft diese Vorabprüfunglower_case_table_names = 1, ob alle Tabellen in Kleinbuchstaben auf der Festplatte gespeichert werden. 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"
      }
  ]
}

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

Um dieses Problem zu beheben, können Sie die Tabelle umbenennen, sodass Kleinbuchstaben verwendet werden, oder Sie können den lower_case_table_names Parameter auf dem DB-Cluster ändern, bevor Sie mit dem Upgrade beginnen.

Stufe der Vorabprüfung: Fehler

Verwendung der entfernten Syntax GROUP BY ASC/DESC

Ab My SQL 8.0.13 wurde die veraltete DESC Syntax für ASC GROUP BY Klauseln entfernt. Abfragen, die auf GROUP BY Sortierung basieren, können jetzt zu unterschiedlichen Ergebnissen führen. 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 im Abschnitt Meine SQL 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 My SQL 8.0 können Routinen die veraltete Identifier-Syntax () nicht mehr enthalten. \".<table>\" Wenn gespeicherte Routinen oder Trigger solche Bezeichner enthalten, schlägt das Upgrade fehl. Beispielsweise ist der folgende .dot_table Verweis 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 richtige Bezeichner-Syntax und das richtige Escaping zu verwenden, ist die Vorabprüfung erfolgreich und das Upgrade kann fortgesetzt werden. Weitere Informationen zu Bezeichnern finden Sie in der Dokumentation Meine Dokumentation unter Schemaobjektnamen. SQL

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

Suchen Sie nach Indizes, die zu groß sind, um mit meinen SQL Versionen über 5.7 zu funktionieren

Bei kompakten oder redundanten Zeilenformaten sollte es nicht möglich sein, einen Index mit einem Präfix zu erstellen, das größer als 767 Byte ist. Vor meiner SQL Version 5.7.35 war dies jedoch möglich. Weitere Informationen finden Sie in den Versionshinweisen zu My SQL 5.7.35.

Auf alle Indizes, die von diesem Fehler betroffen waren, kann nach dem Upgrade auf My 8.0 nicht mehr zugegriffen werden. SQL 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"
      }
  ]
}

Bei der Vorabprüfung wird ein Fehler zurückgegeben, da die test.table_with_large_idx Tabelle einen Index für eine Tabelle enthält, die ein kompaktes oder redundantes Zeilenformat verwendet und größer als 767 Byte ist. Auf diese Tabellen kann nach dem Upgrade auf My 8.0 nicht mehr zugegriffen werden. SQL Bevor Sie mit dem Upgrade fortfahren, führen Sie einen der folgenden Schritte aus:

Hier erstellen wir die Tabelle neu, um den Fehler bei der Vorabprüfung zu beheben. Stellen Sie vor dem Neuaufbau der Tabelle sicher, dass innodb_file_format auf und innodb_default_row_format auf Barracuda gesetzt ist. dynamic Dies SQL sind die Standardeinstellungen in My 5.7. Weitere Informationen finden Sie unter InnoDB-Zeilenformate und InnoDB-Dateiformatverwaltung in der Dokumentation Meine. SQL

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 Neuaufbau 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 vorprüfen: Fehler

Suchen Sie nach ungültigen Tabellen- und Schemanamen, die in My SQL 5.7 verwendet wurden

Bei der Migration zum neuen Datenwörterbuch in My SQL 8.0 darf Ihre Datenbankinstanz keine Schemas oder Tabellen mit dem Präfix enthalten. #mysql50# Wenn solche Objekte existieren, schlägt das Upgrade fehl. Um dieses Problem zu beheben, führen Sie 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 einen ungültigen Namen #mysql50#fix_db_names hat.

Nach dem Fixieren 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 vorprüfen: Fehler

Suchen Sie in 5.7 nach verwaisten Routinen

Wenn bei der Migration zum neuen Datenwörterbuch in My SQL 8.0 gespeicherte Prozeduren in der Datenbank vorhanden sind, für die 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 get_version gespeicherte Prozedur in der dropped_db Datenbank verwaist ist.

Um dieses Verfahren zu bereinigen, 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 beenden, 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 stehen in Konflikt mit neuen Tabellen in My 8.0 SQL

Das in My SQL 8.0 eingeführte neue Atomic Data Dictionary 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. Um Namenskonflikte zu vermeiden, die zu Upgrade-Fehlern führen würden, werden bei der Vorabprüfung alle Tabellennamen im mysql Schema überprüft, um sicherzustellen, dass keiner der neuen Tabellennamen bereits verwendet wird. Wenn dies der Fall ist, 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"
      }
  ]
}

Es wird ein Fehler zurückgegeben, weil tablespaces im mysql Schema eine Tabelle benannt ist. Dies ist einer der neuen Tabellennamen im internen Datenwörterbuch in My SQL 8.0. Sie müssen solche Tabellen vor dem Upgrade mithilfe des RENAME TABLE Befehls umbenennen oder entfernen.

Stufe vorprüfen: Fehler

Partitionierte Tabellen mithilfe von Engines mit nicht-nativer Partitionierung

Laut der My SQL 8.0-Dokumentation bieten derzeit zwei Speicher-Engines native Partitionierungsunterstützung: InnoDB und. NDB Von diesen wird nur InnoDB in Aurora My SQL Version 3 unterstützt, die mit My SQL 8.0 kompatibel ist. Jeder Versuch, partitionierte Tabellen in My SQL 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 My ISAM Table Partitionierung, was eine Aktion erfordert, bevor das Upgrade fortgesetzt werden kann.

Stufe der Vorabprüfung: Fehler

Verwendung des alten temporalen Typs

„Alte Zeitangaben“ beziehen sich auf Spalten vom Typ „Temporal“ (wie TIMESTAMP undDATETIME), die in My SQL Version 5.5 und niedriger erstellt wurden. In My SQL 8.0 wurde die Unterstützung für diese alten temporalen Datentypen entfernt, was bedeutet, dass direkte Upgrades von My SQL 5.7 auf 8.0 nicht möglich sind, wenn die Datenbank diese alten temporalen Datentypen enthält. Um dieses Problem zu beheben, müssen Sie alle Tabellen, die solche alten temporalen Datentypen enthalten, neu erstellen, bevor Sie mit dem Upgrade fortfahren.

Weitere Informationen darüber, wie alte temporale Datentypen in My SQL 5.7 nicht mehr unterstützt wurden, finden Sie in diesem Blog. Weitere Informationen zur Entfernung alter temporaler Datentypen in My SQL 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 wird ein Fehler gemeldettest.55_temporal_table, da sie ein altes temporäres 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 temporäre Festplattenspeicherformat in das neue Format zu konvertieren, das in My SQL 5.6 eingeführt wurde. Weitere Informationen und Voraussetzungen dafür finden Sie in der Dokumentation Meine SQL Dokumentation unter Konvertierung zwischen 3-Byte- und 4-Byte-Unicode-Zeichensätzen.

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

ALTER TABLE ... ENGINE=InnoDB;

Weitere Informationen zur ALTERTABLENeuerstellung von Tabellen finden Sie unter Meine Dokumentation. SQL

Nach dem Neuaufbau der betreffenden Tabelle und dem Neustart des Upgrades ist die Kompatibilitätsprüfung erfolgreich, sodass das Upgrade fortgesetzt werden kann.

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

Stufe vorab prüfen: Fehler

Verwendung partitionierter Tabellen in gemeinsam genutzten Tablespaces

Ab My SQL 8.0.13 wurde die Unterstützung für das Platzieren von Tabellenpartitionen in gemeinsam genutzten Tablespaces entfernt. Verschieben Sie vor dem Upgrade alle derartigen Tabellen von gemeinsam genutzten Tablespaces in Tablespaces. file-per-table

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 im System-Tablespace test.partInnoDBTable befindet.

Um dieses Problem zu beheben, erstellen Sie die test.partInnodbTable Tabelle neu und platzieren Sie die fehlerhafte Partition p1 in einem Tablespace. file-per-table

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

Nutzung von Funktionen, die aus der neuesten Version von My SQL entfernt wurden

In My SQL 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 räumliche Funktionen, 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 My SQL 8.0 entfernte Funktionen in der SQL Dokumentation Meine.

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 test.GetLocationsInPolygon gespeicherte Prozedur zwei entfernte Funktionen verwendet: POLYGONFROMTEXTund POINTFROMTEXT. Außerdem wird empfohlen, die neuen ST_ POLYGONFROMTEXT und ST_ POINTFROMTEXT als Ersatz zu verwenden. Nachdem Sie das Verfahren anhand der Vorschläge erneut erstellt haben, wird die Vorabprüfung erfolgreich abgeschlossen.

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

Stufe der Vorabprüfung: Fehler

Meine SQL Syntaxprüfung für routinemäßige Objekte

In Version SQL 8.0 wurden reservierte Schlüsselwörter eingeführt, die zuvor nicht reserviert waren. Der Upgrade-Prechecker bewertet die Verwendung reservierter Schlüsselwörter in den Namen von Datenbankobjekten sowie in ihren Definitionen und im Hauptteil. Wenn er 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 veröffentlicht. upgrade-prechecks.log Um das Problem zu beheben, müssen Sie diese Objektdefinitionen aktualisieren und alle derartigen Verweise vor dem Upgrade in einfache Anführungszeichen (') setzen. Weitere Informationen zum Maskieren reservierter Wörter in My SQL finden Sie unter String-Literale in der Dokumentation My. SQL

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

Um dieses Problem zu beheben, ü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 Namenexcept, ein neues Schlüsselwort in My SQL 8.0. Erstellen Sie die Prozedur erneut, indem Sie das Zeichenkettenliteral 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 Korrumpieren von Dateien zurückzuführen sind

Wie bereits beschrieben, wurde mit My SQL 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, ACIDkonforme Methode zur Verwaltung von Datenbank-Metadaten und löst damit das „atomareDDL“ Problem des alten dateibasierten Ansatzes. Vor SQL Version 8.0 war es möglich, dass Schemaobjekte verwaist wurden, wenn ein Vorgang unerwartet unterbrochen wurde. DDL Durch die Migration von dateibasierten Metadaten zu den neuen Atomic Data Dictionary-Tabellen 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 eine schemaInconsistencyCheck Vorabprüfung durchgeführt, um sicherzustellen, dass alle Metadatenobjekte des Datenwörterbuches synchron sind. Wenn verwaiste Metadatenobjekte erkannt werden, wird das Upgrade nicht fortgesetzt. Um mit dem Upgrade fortzufahren, bereinigen Sie diese verwaisten Metadatenobjekte.

Wenn Sie bei dieser Vorabprüfung auf Fehler stoßen, wenden Sie sich an den AWS Support, um die Behebung der Metadateninkonsistenz zu beantragen. Alternativ können Sie das Upgrade erneut versuchen, indem Sie einen logischen Speicherauszug durchführen und dann auf einem neuen Aurora My SQL Version 3-DB-Cluster 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 test.schemaInconsistencyCheck_failure Tabelle inkonsistente Metadaten enthält. In diesem Fall ist die Tabelle in den Metadaten der InnoDB-Speicher-Engine (information_schema.INNODB_SYS_TABLES) vorhanden, aber nicht in den Meine SQL Metadaten (information_schema.TABLES).

Stufe vorprüfen: Fehler

Suchen Sie nach Artefakten im Zusammenhang mit der DDL Aurora-Wiederherstellungsfunktion

Im Rahmen der Wiederherstellungsimplementierung der Data Definition Language (DDL) in Aurora My SQL werden Metadaten zu DDL Inflight-Kontoauszügen in den ddl_log_table Tabellen ddl_log_md_table und im mysql Schema verwaltet. Die DDL Wiederherstellungsimplementierung von Aurora wird ab Version 3 nicht unterstützt, da die Funktionalität Teil der neuen Implementierung des Atomic Data Dictionary in My SQL 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, dass Sie das Upgrade versuchen, solange 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 Metadateninkonsistenz zu beantragen. Alternativ können Sie das Upgrade erneut versuchen, indem Sie einen logischen Speicherauszug durchführen und dann auf einem neuen Aurora My SQL Version 3-DB-Cluster wiederherstellen.

Wenn DDL Anweisungen ausgeführt werden, gibt die Precheck-Ausgabe die folgende Meldung aus:

“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."
      }
  ]
}

Bei der Vorabprüfung wurde ein Fehler zurückgegeben, da gleichzeitig mit den Kompatibilitätsprüfungen ein Inflight DDL ausgeführt wurde. Wir empfehlen, dass Sie das Upgrade erneut versuchen, ohne dass es ausgeführt wird. DDLs

Stufe der Vorabprüfung: Fehler

Prüfen Sie, ob die Tabelle vorhanden ist mysql.rds_upgrade_prechecks

Dies ist eine rein interne Vorabprüfung, die vom Dienst durchgeführt wird. RDS Alle Fehler werden beim Upgrade automatisch behoben 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 Metadateninkonsistenz zu beantragen. Alternativ können Sie das Upgrade erneut versuchen, indem Sie einen logischen Speicherauszug durchführen und dann auf einem neuen Aurora My SQL Version 3-DB-Cluster wiederherstellen.

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

Stufe vorprüfen: Fehler

Suchen Sie nach Artefakten im Zusammenhang mit der DDL Aurora-Schnellfunktion

Die schnelle DDL Optimierung wurde in Aurora My SQL Version 2 im Labormodus eingeführt, um die Effizienz einiger DDL Operationen zu verbessern. In Aurora My SQL Version 3 wurde der Labormodus entfernt und die DDL Fast-Implementierung wurde durch die My SQL 8.0-Funktion namens Instant ersetzt. DDL

Vor dem Upgrade auf Aurora My SQL Version 3 müssen alle Tabellen, die Fast DDL im Lab-Modus verwenden, neu erstellt werden, indem der ALTER TABLE ... ENGINE=InnoDB Befehl OPTIMIZE TABLE or ausgeführt wird, um die Kompatibilität mit Aurora My SQL 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."
      }
  ]
}

Bei der Vorabprüfung wird gemeldet, dass in der Tabelle test.test ausstehende DDL Fast-Operationen vorliegen.

Damit das Upgrade fortgesetzt werden kann, können Sie die Tabelle neu erstellen und das Upgrade dann 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 Neuaufbau 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 baumelnder Indexreferenz FULLTEXT

Vor Version SQL 5.6.26 war es möglich, dass nach dem Löschen eines Volltextsuchindex die versteckten FTS_DOC_ID_INDEX Spalten FTS_DOC_ID und die Spalten verwaist waren. Weitere Informationen finden Sie unter Bug #76012.

Wenn Sie Tabellen haben, die in früheren Versionen von My erstellt wurden, SQL in denen dies aufgetreten ist, kann dies dazu führen, dass Upgrades auf Aurora My SQL Version 3 fehlschlagen. Diese Vorabprüfung stellt vor dem Upgrade auf My 8.0 sicher, dass in Ihrem DB-Cluster keine solchen verwaisten oder „hängengebliebenen“ Volltextindizes vorhanden sind. SQL Schlägt diese Vorabprüfung fehl, erstellen Sie alle Tabellen neu, die solche fehlerhaften 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."
      }
  ]
},

Bei der Vorabprüfung wird ein Fehler für die test.table_with_fts_index Tabelle gemeldet, da sie einen fehlerhaften 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 Neuaufbau der Tabelle ist die Vorabprüfung erfolgreich.

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

Stufe der Vorabprüfung: Fehler

Suchen Sie nach Inkonsistenzen im Zusammenhang mit dem Dateipfad ibd

Diese Vorabprüfung gilt nur für Aurora My SQL Version 3.03.0 und niedriger. Wenn bei dieser Vorabprüfung ein Fehler auftritt, führen Sie ein Upgrade auf Aurora My SQL Version 3.04 oder höher durch.

Beispielausgabe:

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

Stufe der Vorabprüfung: Fehler

Suchen Sie nach einem Volltextindex mit der Space-ID als Null

Wenn Sie in My SQL einen Volltextindex zu einer InnoDB-Tabelle 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 Hilfsindextabellen 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 Volltextindizes, die im Precheck-Fehler erwähnt wurden, erneut und versuchen Sie dann erneut, das Upgrade durchzuführen.

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."
      }
  ]
},

Bei der Vorabprüfung wird ein Fehler für die test.fts_space_zero_check Tabelle gemeldet, da sie Hilfstabellen für die Volltextsuche (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

Suchen Sie nach XA-Transaktionen im Status „Vorbereitet“

Während des Upgrade-Prozesses für die Hauptversion ist es wichtig, dass die Aurora My SQL Version 2-DB-Instance ordnungsgemäß heruntergefahren wird. Dadurch wird sichergestellt, dass alle Transaktionen festgeschrieben oder zurückgesetzt werden und dass InnoDB alle Undo-Log-Datensätze gelöscht hat. Da ein Transaktions-Rollback erforderlich ist, kann es, wenn sich in Ihrer Datenbank XA-Transaktionen in einem vorbereiteten Zustand befinden, den Clean Shutdown daran hindern, fortzufahren. Aus diesem Grund kann das Upgrade erst fortgesetzt werden, wenn vorbereitete XA-Transaktionen erkannt werden, wenn Sie Maßnahmen ergreifen, um sie festzuschreiben oder rückgängig zu machen.

Weitere Informationen zum Auffinden von XA-Transaktionen in einem vorbereiteten Zustand mithilfe von XA RECOVER XA-Transaktionen finden Sie unter SQLXA-Transaktionsanweisungen in der SQL Dokumentation Meine Dokumentation. Weitere Informationen zu XA-Transaktionsstatus finden Sie unter XA-Transaktionsstatus in der SQL Dokumentation Meine 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."
      }
  ]
}

Bei dieser Vorabprüfung wird ein Fehler gemeldet, da sich Transaktionen in einem vorbereiteten Zustand befinden, für die ein Commit oder ein Rollback ausgeführt werden sollte.

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

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 Sie, ob das Upgrade für die aktuelle Instanzklasse unterstützt wird

Die Ausführung eines direkten Upgrades von Aurora My SQL Version 2.12.0 oder 2.12.1, bei der die Writer-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 entweder Ihre DB-Instance-Klasse auf db.r6i.24xlarge oder eine kleinere Klasse ändern. Oder Sie können ein Upgrade auf Aurora My SQL Version 2.12.2 oder höher durchführen, wobei das direkte Upgrade auf Aurora My SQL 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 Writer-DB-Instance die Instance-Klasse db.r6i.32xlarge verwendet und auf Aurora My Version 2.12.1 läuft. SQL

Stufe der Vorabprüfung: Fehler

Suchen Sie nach internen 8.0-Benutzern

Diese Vorabprüfung gilt nur für Aurora My SQL Version 3.03.0 und niedriger. Wenn bei dieser Vorabprüfung ein Fehler auftritt, führen Sie ein Upgrade auf Aurora My SQL Version 3.04 oder höher durch.

Beispielausgabe:

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

Stufe der Vorabprüfung: Fehler

Prüfen Sie, ob der RDS Master-Benutzer existiert

My SQL 8 hat ein neues Rechtemodell hinzugefügt, das Rollen - und dynamische Rechte unterstützt, um die Rechteverwaltung einfacher und detaillierter zu gestalten. Im Rahmen dieser Änderung SQL hat Aurora My die neue Version eingeführtrds_superuser_role, die dem Hauptbenutzer der Datenbank beim Upgrade von Aurora My SQL Version 2 auf Version 3 automatisch gewährt wird.

Weitere Informationen zu den Rollen und Rechten, die dem Masterbenutzer in Aurora My zugewiesen wurdenSQL, finden Sie unterBerechtigungen von Hauptbenutzerkonten. Weitere Informationen zum rollenbasierten Rechtemodell in Aurora My SQL Version 3 finden Sie unter. Rollenbasiertes Berechtigungsmodell

Mit dieser Vorabprüfung wird überprüft, ob der Master-Benutzer in der Datenbank vorhanden ist. Wenn der Masterbenutzer nicht existiert, schlägt die Vorabprüfung fehl. Damit das Upgrade fortgesetzt werden kann, müssen Sie den Masterbenutzer neu erstellen, indem Sie das Masterbenutzer-Passwort zurücksetzen oder den Benutzer manuell erstellen. Versuchen Sie dann erneut, das Upgrade durchzuführen. Weitere Informationen zum Zurücksetzen des Masterbenutzerkennworts finden Sie unter. Das Passwort für den Datenbank-Master-Benutzer ändern

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 Masterbenutzerpasswort zurückgesetzt haben, ist die Vorabprüfung erfolgreich und Sie können das Upgrade erneut versuchen.

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

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

Dann ist die Vorabprüfung erfolgreich.

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

Stufe der Vorabprüfung: Fehler

Suchen Sie nach Geometriespalten in Präfixindizes

Ab My SQL 8.0.12 können Sie mithilfe des Datentyps keinen Index mit Präfix mehr für eine Spalte erstellen. GEOMETRY Weitere Informationen finden Sie unter WL #11808.

Wenn solche Indizes existieren, schlägt Ihr Upgrade fehl. Um das Problem zu beheben, löschen Sie die GEOMETRY Indizes mit Präfix in den Tabellen, die in dem Fehler bei der Vorabprüfung erwähnt 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`;"
      }
  ]
}

Bei der Vorabprüfung wird ein Fehler gemeldet, da die test.geom_index_prefix Tabelle einen Index mit einem Präfix für eine 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

Suchen Sie nach Inkonsistenzen im Zusammenhang mit Sonderzeichen in gespeicherten Prozeduren

Vor My SQL 8.0 entsprachen Datenbanknamen, Tabellennamen und andere Objekte Dateien im Datenverzeichnis, d. h. dateibasierten Metadaten. Im Rahmen des Upgrades auf My SQL 8.0 werden alle Datenbankobjekte in die 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 die Prozedurdefinition und der Hauptteil jeder Prozedur überprüft, wenn sie in das neue Datenwörterbuch aufgenommen werden.

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

Diese Vorabprüfung bestätigt, dass die Hauptteile 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 get_version_proc in der test Datenbank aufgerufene Prozedur enthält, die Sonderzeichen im Prozedurkörper 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

Überprüfen Sie, ob der Objekttyp nicht mit dem Schema übereinstimmt sys

Das sys-Schema besteht aus einer Reihe von Objekten und Ansichten in einer SQL My-Datenbank, die Benutzern hilft, Fehler zu beheben, zu optimieren und ihre DB-Instances zu überwachen. Bei der Durchführung eines Hauptversions-Upgrades von Aurora My SQL Version 2 auf Version 3 werden die sys Schema-Ansichten neu erstellt und auf die neuen Aurora My SQL Version 3-Definitionen aktualisiert.

Wenn im Rahmen des Upgrades Objekte im sys Schema mithilfe von Speicher-Engines definiert sind (sys_config/BASE TABLEin INFORMATION_SCHEMA. TABLES) und nicht Ansichten, schlägt das Upgrade fehl. Solche Tabellen finden Sie in der information_schema.tables Tabelle. Dies ist kein erwartetes Verhalten, kann aber in einigen Fällen aufgrund eines Benutzerfehlers auftreten.

Bei dieser Vorabprüfung werden alle sys Schemaobjekte überprüft, um sicherzustellen, dass sie die richtigen Tabellendefinitionen verwenden und dass Ansichten nicht fälschlicherweise als InnoDB oder Meine Tabellen definiert sind. ISAM Um das Problem zu beheben, korrigieren Sie alle zurückgegebenen Objekte manuell, indem Sie sie umbenennen oder löschen. Versuchen Sie dann erneut, das Upgrade durchzuführen.

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 sys.waits_global_by_latency-Ansicht im sys Schema einen Typkonflikt aufweist, der verhindert, dass das Upgrade fortgesetzt wird.

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)

Um dieses Problem zu lösen, 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)

Danach ist die Vorabprüfung erfolgreich.

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

Stufe der Vorabprüfung: Fehler

Überprüfen Sie die Obergrenze für den Spaltennamen in der Ansicht

Die maximal zulässige Länge eines Spaltennamens in My SQL beträgt 64 Zeichen. Vor My SQL 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 Datenbankinstanz vorhanden sind, wird ein Precheck-Fehler zurückgegeben, und das Upgrade schlägt fehl. Damit das Upgrade fortgesetzt werden kann, müssen Sie die betreffenden Ansichten neu erstellen und dabei sicherstellen, dass ihre Spaltenlänge weniger als 64 Zeichen beträgt. Versuchen Sie dann erneut, das Upgrade durchzuführen.

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 test.colname_view_test Ansicht eine Spalte enthältcol2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad, die die maximal zulässige Spaltenlänge von 64 Zeichen überschreitet.

Wenn wir uns die Definition der Ansicht ansehen, können wir die fragliche 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. Achten Sie dabei darauf, 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)

Danach 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

Suchen Sie in winzigen Spalten nach Tabellen mit Indizes, die mit einer Präfixlänge von mehr als 255 Byte definiert sind

Wenn Sie in My einen Index für eine Spalte mit einem binären Datentyp erstellenSQL, müssen Sie der Indexdefinition eine Präfixlänge hinzufügen. Vor My SQL 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 sind TINYTEXT TINYBLOB UND-Spalten, bei denen die maximal zulässige Datengröße 255 Byte beträgt, aber Indexpräfixe, die größer als diese sind, erlaubt waren. Weitere Informationen finden Sie unter InnoDB-Grenzwerte in der SQL Dokumentation Meine.

Wenn diese Vorabprüfung fehlschlägt, löschen Sie den fehlerhaften Index oder reduzieren Sie die Präfixlänge TINYTEXT und die TINYBLOB Spalten des Indexes auf weniger als 255 Byte. Versuchen Sie dann erneut, das Upgrade durchzuführen.

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

Bei der Vorabprüfung wird ein Fehler für die test.tintxt_prefixed_index Tabelle gemeldet, da sie einen Index hatPRIMARY, dessen Präfix in einer TINYTEXT TINYBLOB OR-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 in der TINYTEXT Spalte col1 das Präfix 65 hat. 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

Danach 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

Überprüfen Sie die fehlende Inkonsistenz der InnoDB-Metadaten für die Tabelle mysql.host

Dies ist eine rein interne Vorabprüfung, die vom Dienst durchgeführt wird. RDS Alle Fehler werden beim Upgrade automatisch behoben 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 Metadateninkonsistenz zu beantragen. Alternativ können Sie das Upgrade erneut versuchen, indem Sie einen logischen Speicherauszug durchführen und dann auf einem neuen Aurora My SQL Version 3-DB-Cluster wiederherstellen.

Stufe der Vorabprüfung: Warnung

Überlegungen zum neuen Standard-Authentifizierungs-Plugin

In My SQL 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 My SQL Version 3 ist das Standard-Authentifizierungs-Plugin, das für Datenbankbenutzer verwendet wird, das mysql_native_password Plugin.

Diese Vorabprüfung warnt davor, dass dieses Plugin entfernt und die Standardeinstellung in einer future 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 und Lösungen für caching_sha2_password in der Dokumentation Meine Dokumentation. SQL

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 einer veralteten Flagge MAXDB sql_mode

In My SQL 8.0 wurden eine Reihe veralteter sql_mode-Systemvariablenoptionen entfernt, darunter eine. MAXDB Bei dieser Vorabprüfung werden alle derzeit verbundenen Sitzungen zusammen mit Routinen und Triggern untersucht, um sicherzustellen, dass keine Sitzung auf eine Kombination sql_mode festgelegt wurde, die Folgendes umfasst. MAXDB

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 test.maxdb_stored_routine Routine eine nicht unterstützte Option sql_mode enthält.

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

 > 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)

Um das Problem zu beheben, erstellen Sie die Prozedur erneut, nachdem Sie sql_mode auf dem Client die richtige Einstellung vorgenommen haben.

Erstellen Sie das Verfahren ohne die nicht unterstützten sql_mode Komponenten erneut.

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 Sie, ob einzelne Dollarzeichen in Objektnamen nicht mehr als veraltet verwendet werden

Seit Version SQL8.0.32 ist die Verwendung des Dollarzeichens ($) als erstes Zeichen eines Bezeichners ohne Anführungszeichen veraltet. Wenn Sie Schemas, Tabellen, Ansichten, Spalten oder Routinen haben, die a $ 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 My SQL 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."
      }
  ]
},

Bei der Vorabprüfung wird eine Warnung ausgegeben, da die $deprecated_syntx Tabelle im test Schema a $ als erstes Zeichen enthält.

Stufe der Vorabprüfung: Warnung

Verwendung von Datenbankobjekten, deren Namen mit neuen reservierten Schlüsselwörtern in Konflikt stehen

Diese Prüfung ähnelt der routineSyntaxCheck, da sie prüft, ob Datenbankobjekte verwendet werden, deren Namen mit neuen reservierten Schlüsselwörtern in Konflikt stehen. Sie blockieren zwar keine Upgrades, aber Sie müssen die Warnungen sorgfältig auswerten.

Beispielausgabe:

Bei Verwendung des vorherigen Beispiels mit der benannten except Tabelle 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 My SQL 8.0 zu Fehlern kommen. Überprüfen Sie Ihre Anwendungen zur Bestätigung und testen Sie sie anhand eines Klons oder Snapshots Ihres Aurora My SQL DB-Clusters, der auf Version 3 ausgeführt wird.

Beispiel für eine Anwendungsabfrage ohne Escape-Code, die nach dem Upgrade fehlschlägt:

SELECT * FROM escape;

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

SELECT * FROM 'escape';

Stufe der Vorabprüfung: Warnung

Verwendung des utf8mb3 Zeichensatzes

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

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

Um dieses Problem zu beheben, erstellen Sie die Objekte und Tabellen, auf die verwiesen wird, neu. Weitere Informationen und Voraussetzungen dafür finden Sie unter Konvertieren zwischen 3-Byte- und 4-Byte-Unicode-Zeichensätzen in der Dokumentation Meine SQL Dokumentation.

Stufe der Vorabprüfung: Warnung

Null Werte für Datum, Uhrzeit und Zeitstempel

My setzt SQL jetzt strengere Regeln für die Verwendung von Nullwerten in Datums-, Datetime- und Zeitstempelspalten durch. Wir empfehlen, die NO_ZERO_DATE SQL Modi NO_ZERO_IN_DATE und zusammen mit dem strict Modus zu verwenden, da sie in einer future SQL Version von My mit dem strict Modus 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 Datums-, Datums-, Uhrzeit- und Zeitstempelwerte einfügen, die Nullwerte enthalten. Wir empfehlen jedoch dringend, alle Nullwerte durch gültige Werte zu ersetzen, da sich ihr Verhalten in future ä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

Überprüft, ob die Länge der Liste der Rollback-Segmenthistorie für den Cluster hoch ist

Wie unter erwähnt auroraUpgradeCheckForIncompleteXATransactions, ist es wichtig, dass die Aurora My Version 2-DB-Instance während der Ausführung des SQL Hauptversions-Upgrade-Prozesses ordnungsgemäß heruntergefahren wird. Dadurch wird sichergestellt, dass alle Transaktionen festgeschrieben oder zurückgesetzt werden und dass InnoDB alle Undo-Log-Datensätze gelöscht hat.

Wenn Ihr DB-Cluster eine hohe Länge der Rollback-Segment-Historienliste (HLL) hat, kann dies die Zeit verlängern, die InnoDB benötigt, um die Löschung der Undo-Log-Datensätze abzuschließen, was zu längeren Ausfallzeiten während des Hauptversions-Upgrade-Prozesses führt. Wenn die Vorabprüfung feststellt, dass der Wert HLL auf Ihrem DB-Cluster hoch ist, wird eine Warnung ausgegeben. Dies verhindert zwar nicht, dass Ihr Upgrade fortgesetzt wird, wir empfehlen Ihnen jedoch, den in HLL Ihrem DB-Cluster genau zu überwachen. Wenn Sie es auf einem niedrigen Niveau halten, werden die Ausfallzeiten reduziert, die bei einem Upgrade auf eine Hauptversion erforderlich sind. Weitere Informationen zur Überwachung finden HLL Sie unterDie Länge der InnoDB-Verlaufsliste wurde deutlich erhöht.

Beispiel für eine Ausgabe:

{
  "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 HLL wurde, dass InnoDB Undo auf dem Datenbank-Cluster einen hohen Wert erreicht hat (82989114). Das Upgrade wird zwar fortgesetzt, hängt davon ab, wie viel Rückgängig gemacht werden muss, kann jedoch die während des Upgrade-Vorgangs erforderliche Ausfallzeit verlängern.

Wir empfehlen, dass Sie die offenen Transaktionen in Ihrem DB-Cluster untersuchen, bevor Sie das Upgrade in der Produktionsumgebung ausführen, um sicherzustellen, HLL dass Ihre Größe überschaubar bleibt.

Stufe der Vorabprüfung: Warnung

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

Wie unter erwähnt auroraUpgradeCheckForIncompleteXATransactions, ist es wichtig, dass die Aurora My Version 2-DB-Instance während der Ausführung des SQL Hauptversions-Upgrade-Prozesses ordnungsgemäß heruntergefahren wird. Dadurch wird sichergestellt, dass alle Transaktionen festgeschrieben oder zurückgesetzt werden und dass InnoDB alle Undo-Log-Datensätze gelöscht 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 Clean-Shutdown-Prozesses abzuschließen. Wenn bei der Vorabprüfung Transaktionen mit langer Laufzeit und 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. Wenn Sie es auf einem niedrigen Niveau halten, reduziert sich die Ausfallzeit, die bei einem Upgrade einer Hauptversion 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 Clean-Shutdown-Vorgangs rückgängig gemacht werden müssen. Das Upgrade wird fortgesetzt, aber um die Ausfallzeiten während des Upgrade-Vorgangs zu reduzieren, empfehlen wir Ihnen, dies zu überwachen und zu untersuchen, bevor Sie das Upgrade auf Ihren Produktionsclustern ausführen.

Um aktive Transaktionen auf Ihrer Writer-DB-Instance anzuzeigen, können Sie die Tabelle information_schema.innodb_trx verwenden. Die folgende Abfrage auf der Writer-DB-Instance zeigt aktuelle Transaktionen, Laufzeit, 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. Wenden Sie sich an Meine SQL Dokumentation und Ihr Anwendungsteam, bevor Sie umfangreiche 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 des InnoDB-Transaktionsmanagements und zu den möglichen Auswirkungen der Ausführung und des Rollbacks großer Transaktionen auf Meine SQL Datenbank-Instances finden Sie unter Optimieren der InnoDB-Transaktionsverwaltung in der Dokumentation MeineSQL.

Stufe vorprüfen: Hinweis

Verwendung veralteter Flaggen sql_mode

Darüber hinaus wurden eine Reihe weiterer sql_mode Optionen entfernt:DB2,,MSSQL,MYSQL323,MYSQL40,ORACLE,POSTGRESQL, NO_FIELD_OPTIONSNO_KEY_OPTIONS, undNO_TABLE_OPTIONS. MAXDB Ab My SQL 8.0 kann keiner dieser Werte der sql_mode Systemvariablen zugewiesen werden. Wenn bei dieser Vorabprüfung offene Sitzungen gefunden werden, die diese sql_mode Einstellungen verwenden, stellen Sie sicher, dass Ihre DB-Instance- und DB-Cluster-Parametergruppen sowie die Client-Anwendungen und -Konfigurationen aktualisiert wurden, um sie zu deaktivieren.- Weitere Informationen finden Sie in der Dokumentation Meine SQL.

Beispielausgabe:

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

Informationen zur Behebung dieser Fehler bei der Vorabprüfung finden Sie unter maxdbFlagCheck.

Stufe der Vorabprüfung: Fehler, Warnung oder Hinweis

Durch den Befehl gemeldete Probleme check table x for upgrade

Bevor Sie das Upgrade auf Aurora My SQL Version 3 starten, check table for upgrade wird es für jede Tabelle in den Benutzerschemas in Ihrem DB-Cluster ausgeführt. Diese Vorabprüfung ist nicht dasselbe wie checkTableMysql Schema.

Der check table for upgrade Befehl untersucht Tabellen auf mögliche Probleme, die bei einem Upgrade auf eine neuere Version von My SQL auftreten könnten. Wenn Sie diesen Befehl vor einem Upgrade ausführen, können Sie etwaige Inkompatibilitäten im Voraus identifizieren und beheben, sodass der eigentliche Upgradevorgang 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 bei dieser Vorabprüfung Tabellen zurückgegeben werden, überprüfen Sie diese zusammen mit dem Rückgabecode und der Meldung sorgfältig, bevor Sie das Upgrade starten. Weitere Informationen finden Sie in der CHECKTABLEErklärung unter Meine SQL Dokumentation.

Hier finden Sie ein Beispiel für einen Fehler und ein Beispiel für 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"
      }
  ]
},

Bei der Vorabprüfung wird ein Fehler gemeldet, dass die test.parent Tabelle nicht existiert.

Die mysql-error.log Datei für die Writer-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 Writer-DB-Instance an und starten Sie sie, show engine innodb status\G 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.
.
.

In der LATEST FOREIGN KEY ERROR Meldung wird gemeldet, dass die fk_pname Fremdschlüsseleinschränkung in der test.child Tabelle, die auf die test.parent Tabelle verweist, entweder einen fehlenden Index oder einen Datentypkonflikt aufweist. In meiner SQL Dokumentation zu Fremdschlüsseleinschränkungen heißt es, dass Spalten, auf die in einem Fremdschlüssel verwiesen wird, über einen zugehörigen Index verfügen müssen und dass die übergeordneten/untergeordneten Spalten denselben Datentyp verwenden müssen.

Um zu überprüfen, 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 die Sitzungsvariable foreign_key_checks vorübergehend deaktivieren. Danach können wir sehen, dass die fragliche untergeordnete Einschränkung (fk_pname) verwendet wird, um auf die übergeordnete Tabelle zu verweisen. p_name varchar(20) CHARACTER SET latin1 DEFAULT NULL name varchar(20) NOT NULL Die übergeordnete Tabelle verwendetDEFAULT CHARSET=utf8, aber die p_name Spalte der untergeordneten Tabelle verwendet sielatin1, sodass der Datentypfehler 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)

Um dieses Problem zu lösen, 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 latin1 in der p_name Spaltendefinition explizit verwendet, führen wir ALTER TABLE die Änderung des Zeichensatzes in durchutf8.

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

Bei der Vorabprüfung wird eine Warnung für den delete_audit_trigg Trigger in der test.orders Tabelle gemeldet, da er kein CREATED Attribut hat. Laut „Überprüfung der Versionskompatibilität“ in der SQL Dokumentation zu My dient diese Meldung nur zu Informationszwecken und wird für Trigger gedruckt, die vor My SQL 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 betreffenden Trigger erneut erstellen, und die Vorabprüfung ist ohne Warnungen erfolgreich.

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