' for the table to apply all the pending DDL updates. Then try the upgrade again."
}
]
}
```
Die Vorabprüfung meldet, dass in der Tabelle `test.test` ausstehende Operationen für schnelle DDL vorhanden sind.
Damit das Upgrade fortgesetzt werden kann, können Sie die Tabelle neu erstellen und dann das Upgrade erneut versuchen.
Bevor Sie Tablespaces neu erstellen, finden Sie in der MySQL-Dokumentation unter [Online-DDL-Operationen](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html) Informationen zu den Auswirkungen von Sperren und Datenverschiebungen auf Vordergrundtransaktionen.
```
mysql> optimize table test.test;
+-----------+----------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+-----------+----------+----------+-------------------------------------------------------------------+
| test.test | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| test.test | optimize | status | OK |
+-----------+----------+----------+-------------------------------------------------------------------+
2 rows in set (0.04 sec)
```
Nach dem Neuerstellen der Tabelle ist die Vorabprüfung erfolgreich.
```
{
"id": "auroraFODUpgradeCheck",
"title": "Check for artifacts related to Aurora fast DDL feature",
"status": "OK",
"detectedProblems": []
}
```
**auroraGetDanglingFulltextIndex**
**Stufe der Vorabprüfung: Fehler**
**Tabellen mit hängender `FULLTEXT`-Indexreferenz**
Vor MySQL 5.6.26 war es möglich, dass die versteckten Spalten `FTS_DOC_ID` und `FTS_DOC_ID_INDEX` nach dem Löschen eines Volltextsuchindex verwaisen würden. Weitere Informationen finden Sie unter [Fehler \$176012](https://bugs.mysql.com/bug.php?id=76012).
Wenn Sie Tabellen haben, die in früheren Versionen von MySQL erstellt wurden, bei denen dies aufgetreten ist, kann dies dazu führen, dass Upgrades auf Aurora-MySQL-Version 3 fehlschlagen. Diese Vorabprüfung stellt vor dem Upgrade auf MySQL 8.0 sicher, dass in Ihrem DB-Cluster keine solchen verwaisten oder „hängenden“ Volltextindizes existieren. Wenn diese Vorabprüfung fehlschlägt, erstellen Sie alle Tabellen neu, die solche hängenden Volltextindizes enthalten.
**Beispielausgabe:**
```
{
"id": "auroraGetDanglingFulltextIndex",
"title": "Tables with dangling FULLTEXT index reference",
"status": "OK",
"description": "Error: The following tables contain dangling FULLTEXT index which is not supported. It is recommended to rebuild the table before upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.table_with_fts_index",
"description": "Table `test.table_with_fts_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
}
]
},
```
Die Vorabprüfung meldet einen Fehler für die Tabelle `test.table_with_fts_index`, da sie einen hängenden Volltextindex enthält. Damit das Upgrade fortgesetzt werden kann, müssen Sie die Tabelle neu erstellen, um die Hilfstabellen für den Volltextindex zu bereinigen. Verwenden Sie `OPTIMIZE TABLE test.table_with_fts_index` oder `ALTER TABLE test.table_with_fts_index, ENGINE=INNODB`.
Nach dem Neuerstellen der Tabelle ist die Vorabprüfung erfolgreich.
```
{
"id": "auroraGetDanglingFulltextIndex",
"title": "Tables with dangling FULLTEXT index reference",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForDatafilePathInconsistency**
**Stufe der Vorabprüfung: Fehler**
**Prüfen auf Inkonsistenzen im Zusammenhang mit dem `ibd`-Dateipfad**
Diese Vorabprüfung gilt nur für Aurora-MySQL-Version 3.03.0 und niedriger. Wenn Sie bei dieser Vorabprüfung auf einen Fehler stoßen, versuchen Sie ein Upgrade auf Aurora-MySQL-Version 3.04 oder höher.
**Beispielausgabe:**
```
{
"id": "auroraUpgradeCheckForDatafilePathInconsistency",
"title": "Check for inconsistency related to ibd file path.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForFtsSpaceIdZero**
**Stufe der Vorabprüfung: Fehler**
**Prüfen auf einen Volltextindex mit der Space-ID als Null**
Wenn Sie in MySQL einer InnoDB-Tabelle einen [Volltextindex](https://dev.mysql.com/doc/refman/5.7/en/innodb-fulltext-index.html) hinzufügen, werden eine Reihe von zusätzlichen Index-Tablespaces erstellt. Aufgrund eines [Fehlers](https://bugs.mysql.com/bug.php?id=72132) in früheren Versionen von MySQL, der in Version 5.6.20 behoben wurde, war es möglich, dass diese zusätzlichen Indextabellen im [System-Tablespace](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_system_tablespace) und nicht in ihrem eigenen InnoDB-Tablespace erstellt wurden.
Wenn solche zusätzlichen Tablespaces existieren, schlägt das Upgrade fehl. Erstellen Sie die im Fehler bei der Vorabprüfung genannten Volltextindizes neu und versuchen Sie dann das Upgrade erneut.
**Beispielausgabe:**
```
{
"id": "auroraUpgradeCheckForFtsSpaceIdZero",
"title": "Check for fulltext index with space id as zero",
"status": "OK",
"description": "The auxiliary tables of FTS indexes on the table are created in system table-space. Due to this DDL queries executed on MySQL8.0 shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.fts_space_zero_check",
"description": " The auxiliary tables of FTS indexes on the table 'test.fts_space_zero_check' are created in system table-space due to https://bugs.mysql.com/bug.php?id=72132. In MySQL8.0, DDL queries executed on this table shall cause database unavailability. To avoid that, drop and recreate all the FTS indexes on the table or rebuild the table using ALTER TABLE query before the upgrade."
}
]
},
```
Die Vorabprüfung meldet einen Fehler für die Tabelle `test.fts_space_zero_check`, da sie zusätzliche Tabellen für Volltextsuchen (Full-Text Search, FTS) im System-Tablespace enthält.
Nachdem Sie die mit dieser Tabelle verknüpften FTS-Indizes gelöscht und neu erstellt haben, ist die Vorabprüfung erfolgreich.
Bevor Sie Tablespaces neu erstellen, finden Sie in der MySQL-Dokumentation unter [Partitionierungsoperationen](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html#online-ddl-partitioning) Informationen zu den Auswirkungen von Sperren und Datenverschiebungen auf Vordergrundtransaktionen.
```
{
"id": "auroraUpgradeCheckForFtsSpaceIdZero",
"title": "Check for fulltext index with space id as zero",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForIncompleteXATransactions**
**Stufe der Vorabprüfung: Fehler**
**Prüfen auf XA-Transaktionen im vorbereiteten Zustand**
Während des Upgrade-Prozesses für die Hauptversion ist es wichtig, dass die DB-Instance von Aurora-MySQL-Version 2 [ordnungsgemäß heruntergefahren](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown) wird. Dadurch wird sichergestellt, dass alle Transaktionen festgeschrieben oder rückgängig gemacht werden und dass InnoDB alle Undo-Protokolleinträge bereinigt hat. Da ein Transaktions-Rollback notwendig ist, kann das ordnungsgemäße Herunterfahren blockiert werden, wenn Ihre Datenbank [XA-Transaktionen](https://dev.mysql.com/doc/refman/5.7/en/xa.html) im vorbereiteten Zustand enthält. Aus diesem Grund kann das Upgrade nicht fortgesetzt werden, wenn vorbereitete XA-Transaktionen erkannt werden, bis Sie Maßnahmen ergreifen, um sie entweder festzuschreiben oder rückgängig zu machen.
Weitere Informationen zum Auffinden von XA-Transaktionen im vorbereiteten Zustand mithilfe von `XA RECOVER` finden Sie unter [XA-Transaktions-SQL-Anweisungen](https://dev.mysql.com/doc/refman/5.7/en/xa-statements.html) in der MySQL-Dokumentation. Weitere Informationen zu XA-Transaktionszuständen finden Sie unter [XA-Transaktionszustände](https://dev.mysql.com/doc/refman/5.7/en/xa-states.html) in der MySQL-Dokumentation.
**Beispielausgabe:**
```
{
"id": "auroraUpgradeCheckForIncompleteXATransactions",
"title": "Pre-checks for XA Transactions in prepared state.",
"status": "OK",
"description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "all",
"description": "Your cluster currently has XA transactions in the prepared state. To proceed with the upgrade, commit or rollback these transactions."
}
]
}
```
Diese Vorabprüfung meldet einen Fehler, da sich Transaktionen im vorbereiteten Zustand befinden, die entweder festgeschrieben oder rückgängig gemacht werden sollten.
Nachdem Sie sich bei der Datenbank angemeldet haben, können Sie in der Tabelle [information\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html) und in der `XA RECOVER`-Ausgabe nach weiteren Informationen suchen.
Bevor Sie eine Transaktion festschreiben oder rückgängig machen, empfehlen wir Ihnen, die [MySQL-Dokumentation](https://dev.mysql.com/doc/refman/5.7/en/xa-restrictions.html) und Ihre Anwendungsanforderungen zu lesen.
```
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": []
}
```
**auroraUpgradeCheckForInstanceLimit**
**Stufe der Vorabprüfung: Fehler**
**Prüfen, ob das Upgrade für die aktuelle Instance-Klasse unterstützt wird**
Die Ausführung eines direkten Upgrades von Aurora-MySQL-Version 2.12.0 oder 2.12.1, bei der die Schreiber-[DB-Instance-Klasse](Concepts.DBInstanceClass.md) db.r6i.32xlarge ist, wird derzeit nicht unterstützt. In diesem Fall gibt die Vorabprüfung einen Fehler zurück. Damit das Upgrade fortgesetzt werden kann, können Sie Ihre DB-Instance-Klasse entweder in db.r6i.24xlarge oder kleiner ändern. Oder Sie können ein Upgrade auf Aurora-MySQL-Version 2.12.2 oder höher durchführen, wobei das direkte Upgrade auf Aurora-MySQL-Version 3 auf db.r6i.32xlarge unterstützt wird.
**Beispielausgabe:**
```
{
"id": "auroraUpgradeCheckForInstanceLimit",
"title": "Checks if upgrade is supported on the current instance class",
"status": "OK",
"description": "Upgrade from Aurora Version 2.12.0 and 2.12.1 may fail for 32.xl and above instance class.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "all",
"description": "Upgrade is not supported on this instance size for Aurora MySql Version 2.12.1. Before upgrading to Aurora MySql 3, please consider either: 1. Changing the instance class to 24.xl or lower. -or- 2. Upgrading to patch version 2.12.2 or higher."
}
]
},
```
Die Vorabprüfung gibt einen Fehler zurück, da die Schreiber-DB-Instance die Instance-Klasse db.r6i.32xlarge verwendet und auf Aurora-MySQL-Version 2.12.1 läuft.
**auroraUpgradeCheckForInternalUsers**
**Stufe der Vorabprüfung: Fehler**
**Prüfen auf interne Benutzer von Version 8.0**
Diese Vorabprüfung gilt nur für Aurora-MySQL-Version 3.03.0 und niedriger. Wenn Sie bei dieser Vorabprüfung auf einen Fehler stoßen, versuchen Sie ein Upgrade auf Aurora-MySQL-Version 3.04 oder höher.
**Beispielausgabe:**
```
{
"id": "auroraUpgradeCheckForInternalUsers",
"title": "Check for 8.0 internal users.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForInvalidUtf8mb3CharacterStringInViews**
**Stufe der Vorabprüfung: Fehler**
**Prüfen auf ungültige utf8mb3-Zeichen in einer Ansichtsdefinition**
Diese Vorabprüfung identifiziert Ansichten, die Kommentare mit ungültiger `utf8mb3`-Zeichenkodierung enthalten. In MySQL 8.0 wird eine strengere Validierung auf die Zeichenkodierung in Metadaten angewendet, einschließlich Ansichtskommentaren. Wenn eine Ansichtsdefinition Zeichen enthält, die im `utf8mb3`-Zeichensatz nicht gültig sind, schlägt das Upgrade fehl.
Zum Beheben dieses Problems ändern Sie die Ansichtsdefinition so, dass alle Nicht-BMP-Zeichen entfernt oder ersetzt werden, bevor Sie versuchen, das Upgrade durchzuführen.
**Beispielausgabe:**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3CharacterStringInViews",
"title": "Check for invalid utf8mb3 character string.",
"status": "OK",
"description": "Definition of following view(s) has/have invalid utf8mb3 character string.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "precheck.utf8mb3_invalid_char_view",
"description": "Definition of view precheck.utf8mb3_invalid_char_view contains an invalid utf8mb3 character string. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify the view definition to not use non-BMP characters and try the upgrade again."
}
]
},
```
Die Vorabprüfung meldet, dass die Definition der Ansichtsdefinition `utf8mb3_invalid_char_view` ungültige `utf8mb3`-Zeichen enthält.
Zum Beheben dieses Problems identifizieren Sie die Ansicht, die die nicht unterstützten Zeichen enthält, und aktualisieren die Kommentare. Untersuchen Sie zunächst die Struktur der Ansicht und identifizieren Sie Kommentare.
```
MySQL> SHOW CREATE VIEW precheck.utf8mb3_invalid_char_view\G
*************************** 1. row ***************************
View: utf8mb3_invalid_char_view
Create View: CREATE ALGORITHM=UNDEFINED DEFINER=`admin`@`%` SQL SECURITY DEFINER VIEW `utf8mb3_invalid_char_view` AS select 'This row contains a dolphin 🐬' AS `message`
character_set_client: utf8
collation_connection: utf8_general_ci
1 row in set, 1 warning (0.00 sec)
```
Sobald Sie die Ansicht identifiziert haben, die den Fehler enthält, ersetzen Sie sie mithilfe der `CREATE OR REPLACE VIEW`-Anweisung.
```
MySQL> CREATE OR REPLACE VIEW precheck.utf8mb3_invalid_char_view AS select 'This view definition to not use non-BMP characters' AS message;
```
Nach der Aktualisierung aller Ansichtsdefinitionen, die nicht unterstützte Zeichen enthalten, ist die Vorabprüfung erfolgreich und das Upgrade kann fortgesetzt werden.
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForInvalidUtf8mb3ColumnComments**
**Stufe der Vorabprüfung: Fehler**
**Prüfen auf ungültige utf8mb3-Spaltenkommentare**
Diese Vorabprüfung identifiziert Tabellen, die Spaltenkommentare mit ungültiger `utf8mb3`-Zeichenkodierung enthalten. In MySQL 8.0 wird eine strengere Validierung auf die Zeichenkodierung in Metadaten angewendet, einschließlich Spaltenkommentaren. Wenn Spaltenkommentare Zeichen enthalten, die im utf8mb3-Zeichensatz nicht gültig sind, schlägt das Upgrade fehl.
Zum Beheben dieses Problems müssen Sie die Spaltenkommentare ändern, um alle Nicht-BMP-Zeichen zu entfernen oder zu ersetzen, bevor Sie das Upgrade durchführen. Sie können die `ALTER TABLE`-Anweisung verwenden, um die Spaltenkommentare zu aktualisieren.
**Beispielausgabe:**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"description": "Following table(s) has/have invalid utf8mb3 comments on the column/columns.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.t2",
"description": "Table test.t2 has invalid utf8mb3 comments in it's column/columns. This is due to non-BMP characters in the comment field. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
}
]
}
```
Die Vorabprüfung meldet, dass die Tabelle `test.t2` ungültige `utf8mb3`-Zeichen in einem oder mehreren Spaltenkommentaren enthält, insbesondere aufgrund des Vorhandenseins von Nicht-BMP-Zeichen.
Zum Beheben dieses Problems können Sie die problematischen Spalten identifizieren und ihre Kommentare aktualisieren. Untersuchen Sie zunächst die Tabellenstruktur, um Spalten mit Kommentaren zu identifizieren:
```
mysql> SHOW CREATE TABLE test.t2\G
```
Sobald Sie die Spalten mit problematischen Kommentaren identifiziert haben, aktualisieren Sie sie mithilfe der `ALTER TABLE`-Anweisung. Zum Beispiel:
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT 'Updated comment without non-BMP characters';
```
Alternativ können Sie den Kommentar auch vollständig entfernen:
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT '';
```
Nach der Aktualisierung aller problematischen Spaltenkommentare ist die Vorabprüfung erfolgreich und das Upgrade kann fortgesetzt werden:
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"detectedProblems": []
}
```
Stellen Sie vor dem Ändern von Spaltenkommentaren sicher, dass Anwendungscodes oder Dokumentationen, die von diesen Kommentaren abhängen, entsprechend aktualisiert werden. Erwägen Sie für eine bessere Unicode-Unterstützung eine Migration zum utf8mb4-Zeichensatz, falls Ihre Anwendung Nicht-BMP-Zeichen benötigt.
**auroraUpgradeCheckForInvalidUtf8mb3IndexComments**
**Stufe der Vorabprüfung: Fehler**
**Prüfen auf ungültige utf8mb3-Indexkommentare**
Diese Vorabprüfung identifiziert Tabellen, die Indexkommentare mit ungültiger `utf8mb3`-Zeichenkodierung enthalten. In MySQL 8.0 wird eine strengere Validierung auf die Zeichenkodierung in Metadaten angewendet, einschließlich Indexkommentaren. Wenn ein Indexkommentar Zeichen enthält, die im `utf8mb3`-Zeichensatz nicht gültig sind, schlägt das Upgrade fehl.
Zum Beheben dieses Problems müssen Sie die Indexkommentare ändern, um alle Nicht-BMP-Zeichen zu entfernen oder zu ersetzen, bevor Sie das Upgrade durchführen.
**Beispielausgabe:**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3IndexComments",
"title": "Check for invalid utf8mb3 index comments.",
"status": "OK",
"description": "Following table(s) has/have invalid utf8mb3 comments on the index.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "precheck.utf8mb3_tab_index_comment",
"description": "Table precheck.utf8mb3_tab_index_comment has invalid utf8mb3 comments in it's index. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
}
]
},
```
Die Vorabprüfung meldet, dass die Tabelle `utf8mb3_tab_index_comment` ungültige `utf8mb3`-Zeichen in einem oder mehreren Spaltenkommentaren enthält, insbesondere aufgrund des Vorhandenseins von Nicht-BMP-Zeichen.
Zum Beheben dieses Problems untersuchen Sie zunächst die Tabellenstruktur, um den Index mit problematischen Kommentaren zu identifizieren.
```
MySQL> SHOW CREATE TABLE precheck.utf8mb3_tab_index_comment\G
*************************** 1. row ***************************
Table: utf8mb3_tab_index_comment
Create Table: CREATE TABLE `utf8mb3_tab_index_comment` (
`id` int(11) DEFAULT NULL,
`name` varchar(100) DEFAULT NULL,
KEY `idx_name` (`name`) COMMENT 'Name index 🐬'
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.01 sec)
```
Sobald Sie den Index identifiziert haben, der Kommentare enthält, die nicht unterstützte Zeichen verwenden, löschen Sie den Index und erstellen Sie ihn neu.
Das Löschen und Neuerstellen eines Tabellenindexes kann zu Ausfallzeiten führen. Wir empfehlen, diesen Vorgang während der Wartung zu planen und durchzuführen.
```
MySQL> ALTER TABLE precheck.utf8mb3_tab_index_comment DROP INDEX idx_name;
MySQL> ALTER TABLE precheck.utf8mb3_tab_index_comment ADD INDEX idx_name(name);
```
Das folgende Beispiel zeigt eine andere Möglichkeit, den Index neu zu erstellen.
```
MySQL> ALTER TABLE utf8mb3_tab_index_comment DROP INDEX idx_name, ADD INDEX idx_name (name) COMMENT 'Updated comment without non-BMP characters';
```
Nachdem Sie alle nicht unterstützten Indexkommentare entfernt oder aktualisiert haben, ist die Vorabprüfung erfolgreich und das Upgrade kann fortgesetzt werden.
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3IndexComments",
"title": "Check for invalid utf8mb3 index comments.",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForInvalidUtf8mb3TableComments**
**Stufe der Vorabprüfung: Fehler**
**Prüfen auf ungültige utf8mb3-Zeichen in einer Tabellendefinition**
Diese Vorabprüfung identifiziert Tabellen, die Kommentare mit ungültiger `utf8mb3`-Zeichenkodierung enthalten. In MySQL 8.0 wird eine strengere Validierung auf die Zeichenkodierung in Metadaten angewendet, einschließlich Tabellenkommentaren. Wenn ein Tabellenkommentar Zeichen enthält, die im `utf8mb3`-Zeichensatz nicht gültig sind, schlägt das Upgrade fehl.
Zum Beheben dieses Problems müssen Sie die Tabellenkommentare ändern, um alle Nicht-BMP-Zeichen zu entfernen oder zu ersetzen, bevor Sie das Upgrade durchführen.
**Beispielausgabe:**
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3TableComments",
"title": "Check for invalid utf8mb3 table comments.",
"status": "OK",
"description": "Following table(s) has/have invalid utf8mb3 comments.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "precheck.utf8mb3_table_with_comment",
"description": "Table precheck.utf8mb3_table_with_comment has invalid utf8mb3 comments. This is due to https://bugs.mysql.com/bug.php?id=110177. To fix the inconsistency, we recommend you to modify comment fields to not use non-BMP characters and try the upgrade again."
}
]
},
```
Die Vorabprüfung meldet ungültige `utf8mb3`-Kommentare, die für die `utf8mb3_table_with_comment`-Tabellen in der Testdatenbank definiert wurden.
Zum Beheben dieses Problems identifizieren Sie die Tabelle, die nicht unterstützte Zeichen enthält, und aktualisieren die Kommentare. Untersuchen Sie zunächst die Struktur der Tabelle und identifizieren Sie die Kommentare.
```
MySQL> SHOW CREATE TABLE precheck.utf8mb3_table_with_comment\G
*************************** 1. row ***************************
Table: utf8mb3_table_with_comment
Create Table: CREATE TABLE `utf8mb3_table_with_comment` (
`id` int(11) NOT NULL,
`name` varchar(100) DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COMMENT='This table comment contains flag 🏳️'
1 row in set (0.00 sec)
```
Sobald Sie Tabellenkommentare identifiziert haben, die nicht unterstützte Zeichen enthalten, aktualisieren Sie die Kommentare mit der `ALTER TABLE`-Anweisung.
```
MySQL> ALTER TABLE precheck.utf8mb3_table_with_comment COMMENT='Updated comment without non-BMP characters';
```
Alternativ können Sie den Kommentar auch entfernen.
```
MySQL> ALTER TABLE precheck.utf8mb3_table_with_comment COMMENT='';
```
Nachdem Sie alle nicht unterstützten Zeichen aus allen Tabellenkommentaren entfernt haben, ist die Vorabprüfung erfolgreich.
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3TableComments",
"title": "Check for invalid utf8mb3 table comments.",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForMasterUser**
**Stufe der Vorabprüfung: Fehler**
**Prüfen, ob ein RDS-Master-Benutzer existiert**
MySQL 8 hat ein neues Berechtigungsmodell mit Unterstützung für [Rollen](https://dev.mysql.com/doc/refman/8.0/en/roles.html) und [dynamische Berechtigungen](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#static-dynamic-privileges) hinzugefügt, um die Verwaltung von Berechtigungen einfacher und feiner abgestuft zu gestalten. Im Rahmen dieser Änderung hat Aurora MySQL die neue `rds_superuser_role` eingeführt, die dem Master-Benutzer der Datenbank beim Upgrade von Aurora-MySQL-Version 2 auf Version 3 automatisch gewährt wird.
Weitere Informationen zu den Rollen und Berechtigungen, die dem Master-Benutzer in Aurora MySQL zugewiesen sind, finden Sie unter [Berechtigungen von Hauptbenutzerkonten](UsingWithRDS.MasterAccounts.md). Weitere Informationen zum rollenbasierten Berechtigungsmodell in Aurora-MySQL-Version 3 finden Sie unter [Rollenbasiertes Berechtigungsmodell](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model).
Diese Vorabprüfung stellt sicher, dass der Master-Benutzer in der Datenbank vorhanden ist. Wenn der Master-Benutzer nicht vorhanden ist, schlägt die Vorabprüfung fehl. Damit das Upgrade fortgesetzt werden kann, müssen Sie den Master-Benutzer neu erstellen, indem Sie das Master-Benutzerpasswort zurücksetzen oder den Benutzer manuell erstellen. Versuchen Sie anschließend das Upgrade erneut. Weitere Informationen zum Zurücksetzen des Master-Benutzerpassworts finden Sie unter [Ändern des Passworts für den Master-Benutzer der Datenbank](Aurora.Modifying.md#Aurora.Modifying.Password).
**Beispielausgabe:**
```
{
"id": "auroraUpgradeCheckForMasterUser",
"title": "Check if master user exists",
"status": "OK",
"description": "Throws error if master user has been dropped!",
"documentationLink": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.MasterAccounts.html",
"detectedProblems": [
{
"level": "Error",
"dbObject": "all",
"description": "Your Master User on host '%' has been dropped. To proceed with the upgrade, recreate the master user `reinvent` on default host '%'"
}
]
}
```
Nachdem Sie Ihr Master-Benutzerpasswort zurückgesetzt haben, ist die Vorabprüfung erfolgreich und Sie können das Upgrade erneut versuchen.
Im folgenden Beispiel wird die AWS CLI zum Zurücksetzen des Passworts verwendet. Passwortänderungen werden sofort übernommen.
```
aws rds modify-db-cluster \
--db-cluster-identifier my-db-cluster \
--master-user-password my-new-password
```
Anschließend ist die Vorabprüfung erfolgreich.
```
{
"id": "auroraUpgradeCheckForMasterUser",
title": "Check if master user exists",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForPrefixIndexOnGeometryColumns**
**Stufe der Vorabprüfung: Fehler**
**Prüfen auf Geometriespalten in Präfixindizes**
Ab [MySQL 8.0.12](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-12.html#mysqld-8-0-12-spatial-support) können Sie mit dem Datentyp [GEOMETRY](https://dev.mysql.com/doc/refman/5.7/en/gis-data-formats.html) keinen [Präfix](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix)-Index mehr für eine Spalte erstellen. Weitere Informationen finden Sie unter [WL\$111808](https://dev.mysql.com/worklog/task/?id=11808).
Wenn solche Indizes existieren, schlägt Ihr Upgrade fehl. Zum Beheben des Problems löschen Sie die Präfix-`GEOMETRY`-Indizes in den Tabellen, die im Fehler bei der Vorabprüfung genannt wurden.
**Beispielausgabe:**
```
{
"id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
"title": "Check for geometry columns on prefix indexs",
"status": "OK",
"description": "Consider dropping the prefix Indexes of geometry columns and restart the upgrade.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.geom_index_prefix",
"description": "Table `test`.`geom_index_prefix` has an index `LatLon` on geometry column/s. Mysql 8.0 does not support this type of index on a geometry column https://dev.mysql.com/worklog/task/?id=11808. To upgrade to MySQL 8.0, Run 'DROP INDEX `LatLon` ON `test`.`geom_index_prefix`;"
}
]
}
```
Die Vorabprüfung meldet einen Fehler, da die Tabelle `test.geom_index_prefix` einen Index mit einem Präfix in einer `GEOMETRY`-Spalte enthält.
Nachdem Sie diesen Index gelöscht haben, ist die Vorabprüfung erfolgreich.
```
{
"id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
"title": "Check for geometry columns on prefix indexs",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForSpecialCharactersInProcedures**
**Stufe der Vorabprüfung: Fehler**
**Prüfen auf Inkonsistenzen im Zusammenhang mit Sonderzeichen in gespeicherten Prozeduren**
Vor MySQL 8.0 entsprachen Datenbanknamen, Tabellennamen und andere Objekte Dateien im Datenverzeichnis, also dateibasierten Metadaten. Im Rahmen des Upgrades auf MySQL 8.0 werden alle Datenbankobjekte zu den neuen internen Datenwörterbuchtabellen migriert, die im `mysql`-Schema gespeichert sind, um das neu implementierte [Atomic Data Dictionary](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html) zu unterstützen. Im Rahmen der Migration von gespeicherten Prozeduren werden Prozedurdefinition und -körper jeder Prozedur validiert, wenn sie in das neue Datenwörterbuch aufgenommen werden.
Vor MySQL 8 war es in einigen Fällen möglich, gespeicherte Routinen zu erstellen oder Prozeduren, die Sonderzeichen enthielten, direkt in die Tabelle `mysql.proc` einzufügen. Sie konnten beispielsweise eine gespeicherte Prozedur erstellen, die einen Kommentar mit dem nicht konformen, [geschützten Leerzeichen](https://en.wikipedia.org/wiki/Non-breaking_space) `\xa0` enthielt. Wenn solche Prozeduren gefunden werden, schlägt das Upgrade fehl.
Diese Vorabprüfung stellt sicher, dass die Körper und Definitionen Ihrer gespeicherten Prozeduren keine derartigen Zeichen enthalten. Damit das Upgrade fortgesetzt werden kann, müssen Sie diese gespeicherten Prozeduren ohne versteckte Zeichen oder Sonderzeichen neu erstellen.
**Beispielausgabe:**
```
{
"id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
"title": "Check for inconsistency related to special characters in stored procedures.",
"status": "OK",
"description": "Following procedure(s) has special characters inconsistency.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "information_schema.routines",
"description": "Data Dictionary Metadata is inconsistent for the procedure `get_version_proc` in the database `test` due to usage of special characters in procedure body. To avoid that, drop and recreate the procedure without any special characters before proceeding with the Upgrade."
}
]
}
```
Die Vorabprüfung meldet, dass der DB-Cluster eine Prozedur namens `get_version_proc` in der `test`-Datenbank enthält, deren Prozedurkörper Sonderzeichen enthält.
Nach dem Löschen und Neuerstellen der gespeicherten Prozedur ist die Vorabprüfung erfolgreich, sodass das Upgrade fortgesetzt werden kann.
```
{
"id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
"title": "Check for inconsistency related to special characters in stored procedures.",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForSysSchemaObjectTypeMismatch**
**Stufe der Vorabprüfung: Fehler**
**Prüfen der Nichtübereinstimmung von Objekttypen im `sys`-Schema**
Das [sys-Schema](https://dev.mysql.com/doc/refman/8.0/en/sys-schema.html) besteht aus einer Reihe von Objekten und Ansichten in einer MySQL-Datenbank und unterstützt Benutzer bei der Fehleranalyse, Optimierung und Überwachung ihrer DB-Instances. Wenn ein Hauptversions-Upgrade von Aurora-MySQL-Version 2 auf Version 3 durchgeführt wird, werden die `sys`-Schemaansichten neu erstellt und auf die neuen Definitionen von Aurora-MySQL-Version 3 aktualisiert.
Im Rahmen des Upgrades schlägt dieses fehl, wenn Objekte im `sys`-Schema mit Speicher-Engines (`sys_config/BASE TABLE` in [INFORMATION\$1SCHEMA.TABLES](https://dev.mysql.com/doc/refman/5.7/en/information-schema-tables-table.html)) statt mit Ansichten definiert sind. Solche Tabellen finden Sie in der Tabelle `information_schema.tables`. Dies ist kein erwartetes Verhalten, kann aber in einigen Fällen aufgrund eines Benutzerfehlers auftreten.
Diese Vorabprüfung validiert alle `sys`-Schemaobjekte, um sicherzustellen, dass sie die richtigen Tabellendefinitionen verwenden und dass Ansichten nicht fälschlicherweise als InnoDB- oder MyISAM-Tabellen definiert sind. Zum Beheben des Problems korrigieren Sie alle zurückgegebenen Objekte manuell, indem Sie sie umbenennen oder löschen. Versuchen Sie anschließend das Upgrade erneut.
**Beispielausgabe:**
```
{
"id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
"title": "Check object type mismatch for sys schema.",
"status": "OK",
"description": "Database contains objects with type mismatch for sys schema.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "sys.waits_global_by_latency",
"description": "Your object sys.waits_global_by_latency has a type mismatch. To fix the inconsistency we recommend to rename or remove the object before upgrading (use RENAME TABLE command). "
}
]
}
```
Die Vorabprüfung meldet, dass die Ansicht [sys.waits\$1global\$1by\$1latency](https://dev.mysql.com/doc/refman/5.7/en/sys-waits-global-by-latency.html) im `sys`-Schema einen Typkonflikt aufweist, der die Fortsetzung des Upgrades verhindert.
Nachdem Sie sich bei der DB-Instance angemeldet haben, können Sie sehen, dass dieses Objekt als InnoDB-Tabelle definiert ist, obwohl es eine Ansicht sein sollte.
```
mysql> show create table sys.waits_global_by_latency\G
*************************** 1. row ***************************
Table: waits_global_by_latency
Create Table: CREATE TABLE `waits_global_by_latency` (
`events` varchar(128) DEFAULT NULL,
`total` bigint(20) unsigned DEFAULT NULL,
`total_latency` text,
`avg_latency` text,
`max_latency` text
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
```
Zum Beheben dieses Problems können wir die Ansicht entweder löschen und mit der [richtigen Definition](https://github.com/mysql/mysql-server/blob/mysql-5.7.44/scripts/sys_schema/views/p_s/waits_global_by_latency.sql) neu erstellen oder sie umbenennen. Während des Upgrade-Vorgangs wird sie automatisch mit der richtigen Tabellendefinition erstellt.
```
mysql> RENAME TABLE sys.waits_global_by_latency to sys.waits_global_by_latency_old;
Query OK, 0 rows affected (0.01 sec)
```
Nachdem dies durchgeführt wurde, ist die Vorabprüfung erfolgreich.
```
{
"id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
"title": "Check object type mismatch for sys schema.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForViewColumnNameLength**
**Stufe der Vorabprüfung: Fehler**
**Prüfen der Obergrenze für einen Spaltennamen in einer Ansicht**
Die [maximal zulässige Länge eines Spaltennamens](https://dev.mysql.com/doc/refman/5.7/en/identifier-length.html) in MySQL beträgt 64 Zeichen. Vor MySQL 8.0 war es in einigen Fällen möglich, eine Ansicht mit einem Spaltennamen mit mehr als 64 Zeichen zu erstellen. Wenn solche Ansichten in Ihrer Datenbank-Instance existieren, wird ein Fehler bei der Vorabprüfung zurückgegeben und das Upgrade schlägt fehl. Damit das Upgrade fortgesetzt werden kann, müssen Sie die fraglichen Ansichten neu erstellen und dabei sicherstellen, dass ihre Spaltenlänge weniger als 64 Zeichen beträgt. Versuchen Sie anschließend das Upgrade erneut.
**Beispielausgabe:**
```
{
"id": "auroraUpgradeCheckForViewColumnNameLength",
"title": "Check for upperbound limit related to column name in view.",
"status": "OK",
"description": "Following view(s) has column(s) with length greater than 64.",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.colname_view_test.col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad",
"description": "View `test`.`colname_view_test`has column `col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad` with invalid column name length. To avoid Upgrade errors, view should be altered by renaming the column name so that its length is not 0 and doesn't exceed 64."
}
]
}
```
Die Vorabprüfung meldet, dass die Ansicht `test.colname_view_test` eine `col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad`-Spalte enthält, die die maximal zulässige Spaltenlänge von 64 Zeichen überschreitet.
Wenn wir uns die Ansichtsdefinition ansehen, können wir die problematische Spalte sehen.
```
mysql> desc `test`.`colname_view_test`;
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
| col1 | varchar(20) | YES | | NULL | |
| col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad | int(11) | YES | | NULL | |
+------------------------------------------------------------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)
```
Damit das Upgrade fortgesetzt werden kann, müssen Sie die Ansicht neu erstellen und dabei sicherstellen, dass die Spaltenlänge 64 Zeichen nicht überschreitet.
```
mysql> drop view `test`.`colname_view_test`;
Query OK, 0 rows affected (0.01 sec)
mysql> create view `test`.`colname_view_test`(col1, col2_nopad) as select inf, fodcol from test;
Query OK, 0 rows affected (0.01 sec)
mysql> desc `test`.`colname_view_test`;
+------------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+------------+-------------+------+-----+---------+-------+
| col1 | varchar(20) | YES | | NULL | |
| col2_nopad | int(11) | YES | | NULL | |
+------------+-------------+------+-----+---------+-------+
2 rows in set (0.00 sec)
```
Nachdem dies durchgeführt wurde, ist die Vorabprüfung erfolgreich.
```
{
"id": "auroraUpgradeCheckForViewColumnNameLength",
"title": "Check for upperbound limit related to column name in view.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckIndexLengthLimitOnTinyColumns**
**Stufe der Vorabprüfung: Fehler**
**Prüfen auf Tabellen mit Indizes, die für kleine Spalten mit einer Präfixlänge von mehr als 255 Byte definiert sind**
Wenn Sie einen Index für eine Spalte mit einem [binären Datentyp](https://dev.mysql.com/doc/refman/5.7/en/binary-varbinary.html) in MySQL erstellen, müssen Sie der Indexdefinition eine [Präfixlänge](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix) hinzufügen. Vor MySQL 8.0 war es in einigen Fällen möglich, eine Präfixlänge anzugeben, die größer als die maximal zulässige Größe solcher Datentypen war. Ein Beispiel dafür sind `TINYTEXT`- und `TINYBLOB`-Spalten, bei denen die maximal zulässige Datengröße 255 Byte beträgt, aber auch größere Indexpräfixe zulässig waren. Weitere Informationen finden Sie unter [Limits für InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html) in der MySQL-Dokumentation.
Wenn diese Vorabprüfung fehlschlägt, löschen Sie den problematischen Index oder reduzieren Sie die Präfixlänge von `TINYTEXT`- und `TINYBLOB`-Spalten des Indexes auf weniger als 255 Byte. Versuchen Sie anschließend das Upgrade erneut.
**Beispielausgabe:**
```
{
"id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
"title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
"status": "OK",
"description": "Prefix length of the indexes defined on tiny columns cannot exceed 255 bytes. With utf8mb4 char set, this limits the prefix length supported upto 63 characters only. A larger prefix length was allowed in MySQL5.7 using innodb_large_prefix parameter. This parameter is deprecated in MySQL 8.0.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html, https://dev.mysql.com/doc/refman/8.0/en/storage-requirements.html",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.tintxt_prefixed_index.col1",
"description": "Index 'PRIMARY' on tinytext/tinyblob column `col1` of table `test.tintxt_prefixed_index` is defined with prefix length exceeding 255 bytes. Reduce the prefix length to <=255 bytes depending on character set used. For utf8mb4, it should be <=63."
}
]
}
```
Die Vorabprüfung meldet einen Fehler für die Tabelle `test.tintxt_prefixed_index`, da sie über einen `PRIMARY`-Index verfügt, dessen Präfix für eine TINYTEXT- oder TINYBLOB-Spalte größer als 255 Byte ist.
Wenn wir uns die Definition für diese Tabelle ansehen, können wir sehen, dass der Primärschlüssel einen Präfix von 65 für die `TINYTEXT`-Spalte `col1` aufweist. Da die Tabelle mit dem `utf8mb4`-Zeichensatz definiert wird, der 4 Byte pro Zeichen speichert, überschreitet das Präfix die 255-Byte-Grenze.
```
mysql> show create table `test`.`tintxt_prefixed_index`\G
*************************** 1. row ***************************
Table: tintxt_prefixed_index
Create Table: CREATE TABLE `tintxt_prefixed_index` (
`col1` tinytext NOT NULL,
`col2` tinytext,
`col_id` tinytext,
PRIMARY KEY (`col1`(65))
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 ROW_FORMAT=DYNAMIC
1 row in set (0.00 sec)
```
Wenn Sie das Indexpräfix auf 63 ändern, während Sie den `utf8mb4`-Zeichensatz verwenden, kann das Upgrade fortgesetzt werden.
```
mysql> alter table `test`.`tintxt_prefixed_index` drop PRIMARY KEY, ADD PRIMARY KEY (`col1`(63));
Query OK, 0 rows affected (0.04 sec)
Records: 0 Duplicates: 0 Warnings: 0
```
Nachdem dies durchgeführt wurde, ist die Vorabprüfung erfolgreich.
```
{
"id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
"title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckMissingInnodbMetadataForMysqlHostTable**
**Stufe der Vorabprüfung: Fehler**
**Prüfen der Inkonsistenz fehlender InnoDB-Metadaten für die Tabelle `mysql.host`**
Dies ist eine rein interne Vorabprüfung, die vom RDS-Service durchgeführt wird. Alle Fehler werden beim Upgrade automatisch behandelt und können problemlos ignoriert werden.
Wenn Sie bei dieser Vorabprüfung auf Fehler stoßen, wenden Sie sich an den [AWS Support](https://aws.amazon.com/support), um die Behebung der Metadaten-Inkonsistenz zu beantragen. Alternativ können Sie das Upgrade erneut versuchen, indem Sie einen logischen Dump durchführen und dann in einem neuen DB-Cluster von Aurora-MySQL-Version 3 wiederherstellen.
## Warnungen
Die folgenden Vorabprüfungen generieren Warnungen, wenn die Vorabprüfung fehlschlägt, aber das Upgrade kann fortgesetzt werden.
**Topics**
+ [MySQL-Vorabprüfungen, die Warnungen melden](#precheck-descriptions-warnings.mysql)
+ [Aurora-MySQL-Vorabprüfungen, die Warnungen melden](#precheck-descriptions-warnings.aurora)
### MySQL-Vorabprüfungen, die Warnungen melden
Die folgenden Vorabprüfungen stammen von Community MySQL:
+ [defaultAuthenticationPlugin](#defaultAuthenticationPlugin)
+ [maxdbFlagCheck](#maxdbFlagCheck)
+ [mysqlDollarSignNameCheck](#mysqlDollarSignNameCheck)
+ [reservedKeywordsCheck](#reservedKeywordsCheck)
+ [utf8mb3Check](#utf8mb3Check)
+ [zeroDatesCheck](#zeroDatesCheck)
**defaultAuthenticationPlugin**
**Stufe der Vorabprüfung: Warnung**
**Überlegungen zum neuen Standard-Authentifizierungs-Plugin**
In MySQL 8.0 wurde das `caching_sha2_password`-Authentifizierungs-Plugin eingeführt, das eine sicherere Passwortverschlüsselung und eine bessere Leistung als das veraltete `mysql_native_password`-Plugin bietet. Für Aurora-MySQL-Version 3 ist das für Datenbankbenutzer verwendete Standard-Authentifizierungs-Plugin das `mysql_native_password`-Plugin.
Diese Vorabprüfung warnt davor, dass dieses Plugin entfernt und die Standardeinstellung in einer künftigen Hauptversion geändert wird. Erwägen Sie, vor dieser Änderung die Kompatibilität Ihrer Anwendungsclients und Benutzer zu überprüfen.
Weitere Informationen finden Sie unter [Kompatibilitätsprobleme mit caching\$1sha2\$1password und deren Lösungen](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues) in der MySQL-Dokumentation.
**Beispielausgabe:**
```
{
"id": "defaultAuthenticationPlugin",
"title": "New default authentication plugin considerations",
"description": "Warning: The new default authentication plugin 'caching_sha2_password' offers more secure password hashing than previously used 'mysql_native_password' (and consequent improved client connection authentication). However, it also has compatibility implications that may affect existing MySQL installations. If your MySQL installation must serve pre-8.0 clients and you encounter compatibility issues after upgrading, the simplest way to address those issues is to reconfigure the server to revert to the previous default authentication plugin (mysql_native_password). For example, use these lines in the server option file:\n\n[mysqld]\ndefault_authentication_plugin=mysql_native_password\n\nHowever, the setting should be viewed as temporary, not as a long term or permanent solution, because it causes new accounts created with the setting in effect to forego the improved authentication security.\nIf you are using replication please take time to understand how the authentication plugin changes may impact you.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues\nhttps://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-replication"
},
```
**maxdbFlagCheck**
**Stufe der Vorabprüfung: Warnung**
**Verwendung eines veralteten `MAXDB`-`sql_mode`-Flags**
In MySQL 8.0 wurden eine Reihe von veralteten [sql\$1mode](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_sql_mode)-Systemvariablenoptionen [entfernt](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html), darunter `MAXDB`. Diese Vorabprüfung untersucht alle derzeit verbundenen Sitzungen sowie Routinen und Trigger, um sicherzustellen, dass keine davon `sql_mode` auf eine Kombination gesetzt haben, die `MAXDB` enthält.
**Beispielausgabe:**
```
{
"id": "maxdbFlagCheck",
"title": "Usage of obsolete MAXDB sql_mode flag",
"status": "OK",
"description": "Warning: The following DB objects have the obsolete MAXDB option persisted for sql_mode, which will be cleared during the upgrade. It can potentially change the datatype DATETIME into TIMESTAMP if it is used inside object's definition, and this in turn can change the behavior in case of dates earlier than 1970 or later than 2037. If this is a concern, please redefine these objects so that they do not rely on the MAXDB flag before running the upgrade.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html#mysql-nutshell-removals",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.maxdb_stored_routine",
"description": "PROCEDURE uses obsolete MAXDB sql_mode",
"dbObjectType": "Routine"
}
]
}
```
Die Vorabprüfung meldet, dass die Routine `test.maxdb_stored_routine` eine nicht unterstützte `sql_mode`-Option enthält.
Nachdem Sie sich bei der Datenbank angemeldet haben, können Sie in der Routinedefinition sehen, dass `sql_mode` `MAXDB` enthält.
```
> SHOW CREATE PROCEDURE test.maxdb_stored_routine\G
*************************** 1. row ***************************
Procedure: maxdb_stored_routine
sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,MAXDB,NO_KEY_OPTIONS,NO_TABLE_OPTIONS,NO_FIELD_OPTIONS,NO_AUTO_CREATE_USER
Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)
```
Zum Beheben des Problems erstellen Sie die Prozedur neu, nachdem Sie den richtigen `sql_mode` auf dem Client festgelegt haben.
Gemäß der [MySQL-Dokumentation](https://dev.mysql.com/doc/refman/5.7/en/create-procedure.html) speichert MySQL die `sql_mode`-Einstellung, die gültig ist, wenn eine Routine erstellt oder geändert wird. Die Routine wird stets mit dieser Einstellung ausgeführt, unabhängig von der `sql_mode`-Einstellung beim Start der Routine.
Lesen Sie vor der Änderung von `sql_mode` den Abschnitt [Server-SQL-Modi](https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html) in der MySQL-Dokumentation. Prüfen Sie sorgfältig, welche möglichen Auswirkungen dies auf Ihre Anwendung haben könnte.
Erstellen Sie die Prozedur ohne den nicht unterstützten `sql_mode` neu.
```
mysql > set sql_mode='PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE';
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql > DROP PROCEDURE test.maxdb_stored_routine\G
Query OK, 0 rows affected (0.00 sec)
mysql >
mysql > DELIMITER $$
mysql >
mysql > CREATE PROCEDURE test.maxdb_stored_routine()
-> SQL SECURITY DEFINER
-> BEGIN
-> SELECT * FROM test;
-> END$$
Query OK, 0 rows affected (0.00 sec)
mysql >
mysql > DELIMITER ;
mysql > show create procedure test.maxdb_stored_routine\G
*************************** 1. row ***************************
Procedure: maxdb_stored_routine
sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE
Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)
```
Die Vorabprüfung ist erfolgreich.
```
{
"id": "maxdbFlagCheck",
"title": "Usage of obsolete MAXDB sql_mode flag",
"status": "OK",
"detectedProblems": []
}
```
**mysqlDollarSignNameCheck**
**Stufe der Vorabprüfung: Warnung**
**Prüfen auf die veraltete Verwendung einzelner Dollarzeichen in Objektnamen**
Ab [MySQL 8.0.32](https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-32.html#mysqld-8-0-32-deprecation-removal) ist die Verwendung des Dollarzeichens (`$`) als erstes Zeichen eines Bezeichners ohne Anführungszeichen veraltet. Wenn Sie über Schemas, Tabellen, Ansichten, Spalten oder Routinen verfügen, die ein `$` als erstes Zeichen enthalten, gibt diese Vorabprüfung eine Warnung zurück. Diese Warnung verhindert zwar nicht, dass das Upgrade fortgesetzt wird, wir empfehlen Ihnen jedoch, bald Maßnahmen zu ergreifen, um dieses Problem zu beheben. Ab [MySQL 8.4](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html) geben solche Bezeichner eher einen Syntaxfehler als eine Warnung zurück.
**Beispielausgabe:**
```
{
"id": "mysqlDollarSignNameCheck",
"title": "Check for deprecated usage of single dollar signs in object names",
"status": "OK",
"description": "Warning: The following objects have names with deprecated usage of dollar sign ($) at the begining of the identifier. To correct this warning, ensure, that names starting with dollar sign, also end with it, similary to quotes ($example$). ",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.$deprecated_syntx",
"description": " name starts with $ sign."
}
]
},
```
Die Vorabprüfung gibt eine Warnung aus, da die Tabelle `$deprecated_syntx` im `test`-Schema ein `$` als erstes Zeichen enthält.
**reservedKeywordsCheck**
**Stufe der Vorabprüfung: Warnung**
**Verwendung von Datenbankobjekten, deren Namen mit neuen reservierten Schlüsselwörtern kollidieren**
Diese Prüfung ähnelt [routineSyntaxCheck](#routineSyntaxCheck), da sie die Verwendung von Datenbankobjekten prüft, deren Namen mit neuen reservierten Schlüsselwörtern kollidieren. Obwohl sie Upgrades nicht blockieren, müssen Warnungen sorgfältig bewertet werden.
**Beispielausgabe:**
Bei Verwendung des vorherigen Beispiels mit der Tabelle namens `except` gibt die Vorabprüfung eine Warnung zurück:
```
{
"id": "reservedKeywordsCheck",
"title": "Usage of db objects with names conflicting with new reserved keywords",
"status": "OK",
"description": "Warning: The following objects have names that conflict with new reserved keywords. Ensure queries sent by your applications use `quotes` when referring to them or they will result in errors.",
"documentationLink": "https://dev.mysql.com/doc/refman/en/keywords.html",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.except",
"description": "Table name",
"dbObjectType": "Table"
}
]
}
```
Diese Warnung informiert Sie darüber, dass möglicherweise einige Anwendungsabfragen überprüft werden müssen. Wenn Ihre Anwendungsabfragen [Zeichenfolgenliterale nicht korrekt maskieren](https://dev.mysql.com/doc/refman/8.0/en/string-literals.html), kann es nach dem Upgrade auf MySQL 8.0 zu Fehlern kommen. Überprüfen Sie Ihre Anwendungen zur Bestätigung und testen Sie sie anhand eines Klons oder Snapshots Ihres DB-Clusters von Aurora MySQL, der auf Version 3 ausgeführt wird.
Beispiel für eine nicht maskierte Anwendungsabfrage, die nach dem Upgrade fehlschlägt:
```
SELECT * FROM escape;
```
Beispiel für eine korrekt maskierte Anwendungsabfrage, die nach dem Upgrade erfolgreich ist:
```
SELECT * FROM 'escape';
```
**utf8mb3Check**
**Stufe der Vorabprüfung: Warnung**
**Verwendung des `utf8mb3`-Zeichensatzes**
In MySQL 8.0 ist der `utf8mb3`-Zeichensatz veraltet und wird in einer künftigen MySQL-Hauptversion entfernt. Diese Vorabprüfung ist implementiert, um eine Warnung auszulösen, wenn Datenbankobjekte mit diesem Zeichensatz erkannt werden. Dies verhindert zwar nicht, dass ein Upgrade fortgesetzt wird, wir empfehlen Ihnen jedoch dringend, darüber nachzudenken, Tabellen zum `utf8mb4`-Zeichensatz zu migrieren, der ab MySQL 8.0 die Standardeinstellung ist. Weitere Informationen zu [utf8mb3](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html) und [utf8mb4](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html) finden Sie unter [Konvertierung zwischen 3-Byte- und 4-Byte-Unicode-Zeichensätzen](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html) in der MySQL-Dokumentation.
**Beispielausgabe:**
```
{
"id": "utf8mb3",
"title": "Usage of utf8mb3 charset",
"status": "OK",
"description": "Warning: The following objects use the deprecated utf8mb3 character set. It is recommended to convert them to use utf8mb4 instead, for improved Unicode support. The utf8mb3 character is subject to removal in the future.",
"documentationLink": "https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.t1.col1",
"description": "column's default character set: utf8",
"dbObjectType": "Column"
},
{
"level": "Warning",
"dbObject": "test.t1.col2",
"description": "column's default character set: utf8",
"dbObjectType": "Column"
}
]
}
```
Zum Beheben dieses Problems erstellen Sie die Objekte und Tabellen neu, auf die verwiesen wird. Weitere Informationen und Voraussetzungen dafür finden Sie unter [Konvertierung zwischen 3-Byte- und 4-Byte-Unicode-Zeichensätzen](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html) in der MySQL-Dokumentation.
**zeroDatesCheck**
**Stufe der Vorabprüfung: Warnung**
**Nullwerte für Date, Datetime und Timestamp**
MySQL erzwingt jetzt strengere Regeln für die Verwendung von Nullwerten in Date-, Datetime- und Timestamp-Spalten. Wir empfehlen, die Modi `NO_ZERO_IN_DATE` und `NO_ZERO_DATE SQL` zusammen mit dem Modus `strict` zu verwenden, da sie in einer künftigen MySQL-Version mit dem Modus `strict` zusammengeführt werden.
Wenn die `sql_mode`-Einstellung für eine Ihrer Datenbankverbindungen zum Zeitpunkt der Ausführung der Vorabprüfung diese Modi nicht enthält, wird bei der Vorabprüfung eine Warnung ausgegeben. Benutzer können möglicherweise weiterhin Werte für Date, Datetime und Timestamp einfügen, die Nullwerte enthalten. Wir empfehlen jedoch dringend, alle Nullwerte durch gültige Werte zu ersetzen, da sich ihr Verhalten in Zukunft ändern könnte und sie möglicherweise nicht richtig funktionieren. Da es sich um eine Warnung handelt, werden Upgrades dadurch nicht blockiert. Wir empfehlen Ihnen jedoch, mit der Planung von Maßnahmen zu beginnen.
**Beispielausgabe:**
```
{
"id": "zeroDatesCheck",
"title": "Zero Date, Datetime, and Timestamp values",
"status": "OK",
"description": "Warning: By default zero date/datetime/timestamp values are no longer allowed in MySQL, as of 5.7.8 NO_ZERO_IN_DATE and NO_ZERO_DATE are included in SQL_MODE by default. These modes should be used with strict mode as they will be merged with strict mode in a future release. If you do not include these modes in your SQL_MODE setting, you are able to insert date/datetime/timestamp values that contain zeros. It is strongly advised to replace zero values with valid ones, as they may not work correctly in the future.",
"documentationLink": "https://lefred.be/content/mysql-8-0-and-wrong-dates/",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "global.sql_mode",
"description": "does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
},
{
"level": "Warning",
"dbObject": "session.sql_mode",
"description": " of 10 session(s) does not contain either NO_ZERO_DATE or NO_ZERO_IN_DATE which allows insertion of zero dates"
}
]
}
```
### Aurora-MySQL-Vorabprüfungen, die Warnungen melden
Die folgenden Vorabprüfungen sind spezifisch für Aurora MySQL:
+ [auroraUpgradeCheckForRollbackSegmentHistoryLength](#auroraUpgradeCheckForRollbackSegmentHistoryLength)
+ [auroraUpgradeCheckForUncommittedRowModifications](#auroraUpgradeCheckForUncommittedRowModifications)
**auroraUpgradeCheckForRollbackSegmentHistoryLength**
**Stufe der Vorabprüfung: Warnung**
**Prüft, ob die Länge der Liste des Rollback-Segmentverlaufs für den Cluster hoch ist**
Wie in [auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions) erwähnt, ist es wichtig, dass die DB-Instance von Aurora-MySQL-Version 2 während des Upgrade-Prozesses für die Hauptversion [ordnungsgemäß heruntergefahren](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown) wird. Dadurch wird sichergestellt, dass alle Transaktionen festgeschrieben oder rückgängig gemacht werden und dass InnoDB alle Undo-Protokolleinträge bereinigt hat.
Wenn Ihr DB-Cluster eine hohe Länge der Liste des Rollback-Segmentverlaufs (History List Length, HLL) aufweist, kann das die Zeit verlängern, die InnoDB benötigt, um die Undo-Protokolleinträge zu bereinigen. Dies führt zu längeren Ausfallzeiten während des Upgrade-Prozesses für die Hauptversion. Wenn die Vorabprüfung feststellt, dass der HLL-Wert in Ihrem DB-Cluster hoch ist, wird eine Warnung ausgegeben. Dies verhindert zwar nicht, dass Ihr Upgrade fortgesetzt wird, wir empfehlen Ihnen jedoch, die HLL in Ihrem DB-Cluster genau zu überwachen. Ein möglichst niedriger Wert reduziert die Ausfallzeit, die während des Hauptversions-Upgrade erforderlich ist. Weitere Informationen zur Überwachung der HLL finden Sie unter [Die Länge der InnoDB-Verlaufsliste wurde deutlich erhöht](proactive-insights.history-list.md).
**Beispielausgabe:**
```
{
"id": "auroraUpgradeCheckForRollbackSegmentHistoryLength",
"title": "Checks if the rollback segment history length for the cluster is high",
"status": "OK",
"description": "Rollback Segment History length is greater than 1M. Upgrade may take longer time.",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "information_schema.innodb_metrics",
"description": "The InnoDB undo history list length('trx_rseg_history_len') is 82989114. Upgrade may take longer due to purging of undo information for old row versions."
}
]
}
```
Die Vorabprüfung gibt eine Warnung zurück, da festgestellt wurde, dass die InnoDB-Undo-HLL im Datenbank-Cluster hoch war (82989114). Obwohl das Upgrade fortgesetzt wird, kann sich die erforderliche Ausfallzeit während des Upgrade-Vorgangs je nach Umfang der zu bereinigenden Undo-Daten verlängern.
Wir empfehlen Ihnen, [offene Transaktionen in Ihrem DB-Cluster zu untersuchen](proactive-insights.history-list.md), bevor Sie das Upgrade in der Produktion ausführen, um sicherzustellen, dass Ihre HLL eine überschaubare Größe hat.
**auroraUpgradeCheckForUncommittedRowModifications**
**Stufe der Vorabprüfung: Warnung**
**Prüft, ob es viele nicht festgeschriebene Zeilenänderungen gibt**
Wie in [auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions) erwähnt, ist es wichtig, dass die DB-Instance von Aurora-MySQL-Version 2 während des Upgrade-Prozesses für die Hauptversion [ordnungsgemäß heruntergefahren](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown) wird. Dadurch wird sichergestellt, dass alle Transaktionen festgeschrieben oder rückgängig gemacht werden und dass InnoDB alle Undo-Protokolleinträge bereinigt hat.
Wenn Ihr DB-Cluster über Transaktionen verfügt, die eine große Anzahl von Zeilen geändert haben, kann dies die Zeit verlängern, die InnoDB benötigt, um ein Rollback dieser Transaktion als Teil des ordnungsgemäßen Herunterfahrens abzuschließen. Wenn bei der Vorabprüfung lang laufende Transaktionen mit einer großen Anzahl von geänderten Zeilen in Ihrem DB-Cluster festgestellt werden, wird eine Warnung ausgegeben. Dies verhindert zwar nicht, dass Ihr Upgrade fortgesetzt wird, wir empfehlen Ihnen jedoch, die Größe der aktiven Transaktionen in Ihrem DB-Cluster genau zu überwachen. Ein möglichst niedriger Wert reduziert die Ausfallzeit, die während des Hauptversions-Upgrade erforderlich ist.
**Beispielausgabe:**
```
{
"id": "auroraUpgradeCheckForUncommittedRowModifications",
"title": "Checks if there are many uncommitted modifications to rows",
"status": "OK",
"description": "Database contains uncommitted row changes greater than 10M. Upgrade may take longer time.",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "information_schema.innodb_trx",
"description": "The database contains 11000000 uncommitted row change(s) in 1 transaction(s). Upgrade may take longer due to transaction rollback."
}
]
},
```
Die Vorabprüfung meldet, dass der DB-Cluster eine Transaktion mit 11 000 000 nicht festgeschriebenen Zeilenänderungen enthält, die während des ordnungsgemäßen Herunterfahrens rückgängig gemacht werden müssen. Das Upgrade wird fortgesetzt, aber um die Ausfallzeiten während des Upgrade-Prozesses zu reduzieren, empfehlen wir Ihnen, dies zu überwachen und zu untersuchen, bevor Sie das Upgrade in Ihren Produktions-Clustern ausführen.
Wenn Sie aktive Transaktionen in Ihrer Schreiber-DB-Instance anzeigen möchten, können Sie die Tabelle [information\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html) verwenden. Die folgende Abfrage der Schreiber-DB-Instance zeigt aktuelle Transaktionen, die Laufzeit, den Status und geänderte Zeilen für den DB-Cluster.
```
# Example of uncommitted transaction
mysql> SELECT trx_started,
TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
trx_mysql_thread_id AS show_processlist_connection_id,
trx_id,
trx_state,
trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| trx_started | seconds_trx_has_been_running | show_processlist_connection_id | trx_id | trx_state | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
| 2024-08-12 18:32:52 | 1592 | 20041 | 52866130 | RUNNING | 11000000 |
+---------------------+------------------------------+--------------------------------+----------+-----------+---------------+
1 row in set (0.01 sec)
# Example of transaction rolling back
mysql> SELECT trx_started,
TIME_TO_SEC(TIMEDIFF(now(), trx_started)) AS seconds_trx_has_been_running,
trx_mysql_thread_id AS show_processlist_connection_id,
trx_id,
trx_state,
trx_rows_modified AS rows_modified
FROM information_schema.innodb_trx;
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| trx_started | seconds_trx_has_been_running | show_processlist_connection_id | trx_id | trx_state | rows_modified |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
| 2024-08-12 18:32:52 | 1719 | 20041 | 52866130 | ROLLING BACK | 10680479 |
+---------------------+------------------------------+--------------------------------+----------+--------------+---------------+
1 row in set (0.01 sec)
```
Nachdem die Transaktion festgeschrieben oder rückgängig gemacht wurde, gibt die Vorabprüfung keine Warnung mehr zurück. Konsultieren Sie die MySQL-Dokumentation und Ihr Anwendungsteam, bevor Sie große Transaktionen rückgängig machen, da das Rollback je nach Transaktionsgröße einige Zeit in Anspruch nehmen kann.
```
{
"id": "auroraUpgradeCheckForUncommittedRowModifications",
"title": "Checks if there are many uncommitted modifications to rows",
"status": "OK",
"detectedProblems": []
},
```
Weitere Informationen zur Optimierung der InnoDB-Transaktionsverwaltung und zu den möglichen Auswirkungen der Ausführung und des Rollbacks großer Transaktionen in MySQL-Datenbank-Instances finden Sie unter [Optimieren der InnoDB-Transaktionsverwaltung](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html) in der MySQL-Dokumentation.
## Hinweise
Die folgende Vorabprüfung generiert einen Hinweis, wenn die Vorabprüfung fehlschlägt, aber das Upgrade kann fortgesetzt werden.
**sqlModeFlagCheck**
**Stufe der Vorabprüfung: Hinweis**
**Verwendung von veralteten `sql_mode`-Flags**
Zusätzlich zu `MAXDB` wurden eine Reihe weiterer `sql_mode`-Optionen [entfernt](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html): `DB2`, `MSSQL`, `MYSQL323`, `MYSQL40`, `ORACLE`, `POSTGRESQL`, `NO_FIELD_OPTIONS`, `NO_KEY_OPTIONS` und `NO_TABLE_OPTIONS`. Ab MySQL 8.0 kann keiner dieser Werte der Systemvariablen `sql_mode` zugewiesen werden. Wenn diese Vorabprüfung offene Sitzungen findet, die diese `sql_mode`-Einstellungen verwenden, stellen Sie sicher, dass Ihre DB-Instance- und DB-Cluster-Parametergruppen sowie Client-Anwendungen und -Konfigurationen aktualisiert werden, um sie zu deaktivieren. Weitere Informationen finden Sie in der [MySQL-Dokumentation](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html).
**Beispielausgabe:**
```
{
"id": "sqlModeFlagCheck",
"title": "Usage of obsolete sql_mode flags",
"status": "OK",
"detectedProblems": []
}
```
Informationen zum Beheben dieser Fehler bei der Vorabprüfung finden Sie unter [maxdbFlagCheck](#maxdbFlagCheck).
## Fehler, Warnungen oder Hinweise
Die folgende Vorabprüfung kann je nach Ausgabe der Vorabprüfung einen Fehler, eine Warnung oder einen Hinweis zurückgeben.
**checkTableOutput**
**Stufe der Vorabprüfung: Fehler, Warnung oder Hinweis**
**Probleme, die vom Befehl `check table x for upgrade` gemeldet wurden**
Bevor das Upgrade auf Aurora-MySQL-Version 3 gestartet wird, wird `check table for upgrade` für jede Tabelle in den Benutzerschemas in Ihrem DB-Cluster ausgeführt. Diese Vorabprüfung entspricht nicht [checkTableMysqlSchema](#checkTableMysqlSchema).
Der Befehl `check table for upgrade` untersucht Tabellen auf mögliche Probleme, die bei einem Upgrade auf eine neuere Version von MySQL auftreten könnten. Das Ausführen dieses Befehls vor dem Upgrade kann helfen, etwaige Inkompatibilitäten im Voraus zu identifizieren und zu beheben, sodass der eigentliche Upgrade-Prozess reibungsloser abläuft.
Mit diesem Befehl werden verschiedene Prüfungen für jede Tabelle durchgeführt, z. B. die folgenden:
+ Überprüfung, ob die Tabellenstruktur und die Metadaten mit der Ziel-MySQL-Version kompatibel sind
+ Prüfung auf veraltete oder entfernte Funktionen, die von der Tabelle verwendet werden
+ Sicherstellung, dass die Tabelle ordnungsgemäß und ohne Datenverlust aktualisiert werden kann
Im Gegensatz zu anderen Vorabprüfungen kann sie je nach `check table`-Ausgabe einen Fehler, eine Warnung oder einen Hinweis zurückgeben. Wenn diese Vorabprüfung Tabellen zurückgibt, überprüfen Sie diese zusammen mit dem Rückgabecode und der Meldung sorgfältig, bevor Sie das Upgrade starten. Weitere Informationen finden Sie unter [CHECK-TABLE-Anweisung](https://dev.mysql.com/doc/refman/5.7/en/check-table.html) in der MySQL-Dokumentation.
Hier finden Sie ein Beispiel für einen Fehler und eine Warnung.
**Beispiel für einen Fehler:**
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": [
{
"level": "Error",
"dbObject": "test.parent",
"description": "Table 'test.parent' doesn't exist"
}
]
},
```
Die Vorabprüfung meldet einen Fehler, der besagt, dass die Tabelle `test.parent` nicht existiert.
Die `mysql-error.log`-Datei für die Schreiber-DB-Instance zeigt, dass ein Fremdschlüsselfehler vorliegt.
```
2024-08-13T15:32:10.676893Z 62 [Warning] InnoDB: Load table `test`.`parent` failed, the table has missing foreign key indexes. Turn off 'foreign_key_checks' and try again.
2024-08-13T15:32:10.676905Z 62 [Warning] InnoDB: Cannot open table test/parent from the internal data dictionary of InnoDB though the .frm file for the table exists.
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html for how to resolve the issue.
```
Melden Sie sich bei der Schreiber-DB-Instance an und führen Sie `show engine innodb status\G` aus, um weitere Informationen zum Fremdschlüsselfehler zu erhalten.
```
mysql> show engine innodb status\G
*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=====================================
2024-08-13 15:33:33 0x14ef7b8a1700 INNODB MONITOR OUTPUT
=====================================
.
.
.
------------------------
LATEST FOREIGN KEY ERROR
------------------------
2024-08-13 15:32:10 0x14ef6dbbb700 Error in foreign key constraint of table test/child:
there is no index in referenced table which would contain
the columns as the first columns, or the data types in the
referenced table do not match the ones in table. Constraint:
,
CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
The index in the foreign key in table is p_name_idx
Please refer to http://dev.mysql.com/doc/refman/5.7/en/innodb-foreign-key-constraints.html for correct foreign key definition.
.
.
```
Die `LATEST FOREIGN KEY ERROR`-Meldung gibt an, dass die `fk_pname`-Fremdschlüsseleinschränkung in der Tabelle `test.child`, die auf die Tabelle `test.parent` verweist, entweder einen fehlenden Index oder einen Datentypkonflikt aufweist. Die MySQL-Dokumentation zu [Fremdschlüsseleinschränkungen](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html) besagt, dass Spalten, auf die in einem Fremdschlüssel verwiesen wird, einen zugehörigen Index haben müssen und dass die übergeordneten/untergeordneten Spalten denselben Datentyp verwenden müssen.
Wenn Sie überprüfen möchten, ob dies mit einem fehlenden Index oder einer Nichtübereinstimmung des Datentyps zusammenhängt, melden Sie sich bei der Datenbank an und überprüfen Sie die Tabellendefinitionen, indem Sie vorübergehend die Sitzungsvariable [foreign\$1key\$1checks](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html#foreign-key-checks) deaktivieren. Danach können wir sehen, dass die fragliche untergeordnete Einschränkung (`fk_pname`) `p_name varchar(20) CHARACTER SET latin1 DEFAULT NULL` verwendet, um auf die übergeordnete Tabelle `name varchar(20) NOT NULL` zu verweisen. Die übergeordnete Tabelle verwendet `DEFAULT CHARSET=utf8`, aber die Spalte `p_name` der untergeordneten Tabelle verwendet `latin1`, sodass der Fehler wegen fehlender Datentypübereinstimmung ausgelöst wird.
```
mysql> show create table parent\G
ERROR 1146 (42S02): Table 'test.parent' doesn't exist
mysql> show create table child\G
*************************** 1. row ***************************
Table: child
Create Table: CREATE TABLE `child` (
`id` int(11) NOT NULL,
`p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `p_name_idx` (`p_name`),
CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
mysql> set foreign_key_checks=0;
Query OK, 0 rows affected (0.00 sec)
mysql> show create table parent\G
*************************** 1. row ***************************
Table: parent
Create Table: CREATE TABLE `parent` (
`name` varchar(20) NOT NULL,
PRIMARY KEY (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
mysql> show create table child\G
*************************** 1. row ***************************
Table: child
Create Table: CREATE TABLE `child` (
`id` int(11) NOT NULL,
`p_name` varchar(20) CHARACTER SET latin1 DEFAULT NULL,
PRIMARY KEY (`id`),
KEY `p_name_idx` (`p_name`),
CONSTRAINT `fk_pname` FOREIGN KEY (`p_name`) REFERENCES `parent` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
1 row in set (0.00 sec)
```
Zum Beheben dieses Problems können wir entweder die untergeordnete Tabelle so ändern, dass sie denselben Zeichensatz wie die übergeordnete Tabelle verwendet, oder die übergeordnete Tabelle so ändern, dass sie denselben Zeichensatz wie die untergeordnete Tabelle verwendet. Da die untergeordnete Tabelle hier explizit `latin1` in der `p_name`-Spaltendefinition verwendet, führen wir `ALTER TABLE` aus, um den Zeichensatz in `utf8` zu ändern.
```
mysql> alter table child modify p_name varchar(20) character set utf8 DEFAULT NULL;
Query OK, 0 rows affected (0.06 sec)
Records: 0 Duplicates: 0 Warnings: 0
mysql> flush tables;
Query OK, 0 rows affected (0.01 sec)
```
Danach ist die Vorabprüfung erfolgreich und das Upgrade kann fortgesetzt werden.
**Beispiel für eine Warnung:**
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": [
{
"level": "Warning",
"dbObject": "test.orders",
"description": "Trigger test.orders.delete_audit_trigg does not have CREATED attribute."
}
]
}
```
Die Vorabprüfung meldet eine Warnung für den Trigger `delete_audit_trigg` in der Tabelle `test.orders`, da er kein `CREATED`-Attribut aufweist. Laut [Überprüfen der Versionskompatibilität](https://dev.mysql.com/doc/refman/5.7/en/check-table.html#check-table-version-compatibility) in der MySQL-Dokumentation ist diese Meldung informativ und wird für Trigger angezeigt, die vor MySQL 5.7.2 erstellt wurden.
Da es sich um eine Warnung handelt, verhindert sie nicht, dass das Upgrade fortgesetzt wird. Wenn Sie das Problem jedoch beheben möchten, können Sie den fraglichen Trigger neu erstellen und die Vorabprüfung ist ohne Warnungen erfolgreich.
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": []
},
```
# Erläuterung der Durchführung eines direkten Upgrades
Sehen Sie sich die Hintergrundinformationen unter [Funktionsweise des Aurora MySQL direkten Upgrade der Hauptversion](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence) an.
Führen Sie alle Planungen und Tests vor dem Upgrade durch, wie unter [Planen eines Hauptversionsupgrades für einen Aurora MySQL-Cluster](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Planning) beschrieben.
## Konsole
Im folgenden Beispiel wird der `mydbcluster-cluster`-DB-Cluster auf Aurora-MySQL-Version 3.04.1 aktualisiert.
**Aktualisieren der Hauptversion eines Aurora MySQL-DB-Clusters**
1. Melden Sie sich bei der AWS-Managementkonsole an und öffnen Sie die Amazon-RDS-Konsole unter [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/).
1. Wenn Sie eine benutzerdefinierte Parametergruppe für den ursprünglichen DB-Cluster verwendet haben, erstellen Sie eine entsprechende Parametergruppe, die mit der neuen Hauptversion kompatibel ist. Nehmen Sie alle erforderlichen Anpassungen an den Konfigurationsparametern in dieser neuen Parametergruppe vor. Weitere Informationen finden Sie unter [Wie sich direkte Upgrades auf die Parametergruppen für einen Cluster auswirken](#AuroraMySQL.Upgrading.ParamGroups).
1. Wählen Sie im Navigationsbereich **Databases (Datenbanken)** aus.
1. Wählen Sie den DB-Cluster aus, den Sie ändern möchten.
1. Wählen Sie **Ändern** aus.
1. Wählen Sie unter **Version** eine neue Aurora-MySQL-Hauptversion aus.
Wir empfehlen im Allgemeinen, die neueste Nebenversion der Hauptversion zu verwenden. Hier wählen wir die aktuelle Standardversion.
![\[Direktes Upgrade eines DB-Clusters von Aurora MySQL von Version 2 auf Version 3\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/ams-upgrade-v2-v3.png)
1. Klicken Sie auf **Weiter**.
1. Geben Sie auf der nächsten Seite an, wann das Upgrade durchgeführt werden soll. Wählen Sie **During the next scheduled maintenance window (Während des nächsten geplanten Wartungsfensters)** oder **Sofort** aus.
1. (Optional) Überprüfen Sie während des Upgrades regelmäßig die Seite **Ereignisse** in der RDS-Konsole. Auf diese Weise können Sie den Fortschritt des Upgrades überwachen und etwaige Probleme erkennen. Wenn das Upgrade auf Probleme stößt, lesen Sie [Problembehandlung für Aurora MySQL direkte Upgrades](AuroraMySQL.Upgrading.Troubleshooting.md) für zu ergreifende Schritte.
1. Wenn Sie zu Beginn dieses Vorgangs eine neue Parametergruppe erstellt haben, ordnen Sie die benutzerdefinierte Parametergruppe Ihrem aktualisierten Cluster zu. Weitere Informationen finden Sie unter [Wie sich direkte Upgrades auf die Parametergruppen für einen Cluster auswirken](#AuroraMySQL.Upgrading.ParamGroups).
**Anmerkung**
Wenn Sie diesen Schritt ausführen, müssen Sie den Cluster erneut neu starten, um die neue Parametergruppe anzuwenden.
1. (Optional) Löschen Sie nach dem Upgrade den manuellen Snapshot, den Aurora zu Beginn des Upgrades erstellt hat.
## AWS CLI
Um die Hauptversion eines Aurora-MySQL-DB-Clusters zu aktualisieren, verwenden Sie den AWS CLI-Befehl [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) mit den folgenden erforderlichen Parametern:
+ `--db-cluster-identifier`
+ `--engine-version`
+ `--allow-major-version-upgrade`
+ `--apply-immediately` oder `--no-apply-immediately`
Wenn Ihr Cluster benutzerdefinierte Parametergruppen verwendet, schließen Sie auch eine oder beide der folgenden Optionen ein:
+ `--db-cluster-parameter-group-name`, wenn der Cluster eine benutzerdefinierte Cluster-Parametergruppe verwendet
+ `--db-instance-parameter-group-name`, falls Instances im Cluster eine benutzerdefinierte DB-Parametergruppe verwenden
Im folgenden Beispiel wird der `sample-cluster`-DB-Cluster auf Aurora-MySQL-Version 3.04.1 aktualisiert. Das Upgrade erfolgt sofort, anstatt auf das nächste Wartungsfenster zu warten.
**Example**
Für Linux, macOS oder Unix:
```
aws rds modify-db-cluster \
--db-cluster-identifier sample-cluster \
--engine-version 8.0.mysql_aurora.3.04.1 \
--allow-major-version-upgrade \
--apply-immediately
```
Für Windows:
```
aws rds modify-db-cluster ^
--db-cluster-identifier sample-cluster ^
--engine-version 8.0.mysql_aurora.3.04.1 ^
--allow-major-version-upgrade ^
--apply-immediately
```
Sie können andere CLI-Befehle mit `modify-db-cluster` kombinieren, um einen automatisierten End-to-End-Prozess zum Durchführen und Überprüfen von Upgrades zu erstellen. Weitere Informationen und Beispiele finden Sie unter [Aurora MySQL direktes Upgrade](AuroraMySQL.Upgrading.Tutorial.md).
**Anmerkung**
Wenn Ihr Cluster Teil einer Aurora globalen Datenbank ist, unterscheidet sich das Verfahren des direkten Upgrades geringfügig. Sie rufen die Befehlsoperation [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) statt `modify-db-cluster` auf. Weitere Informationen finden Sie unter [In-Situ-Hauptversions-Upgrades für globale Datenbanken](#AuroraMySQL.Upgrading.GlobalDB).
## RDS-API
Verwenden Sie zum Aktualisieren der Hauptversion eines DB-Clusters von Aurora MySQL die RDS-API-Operation [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html) mit den folgenden erforderlichen Parametern:
+ `DBClusterIdentifier`
+ `Engine`
+ `EngineVersion`
+ `AllowMajorVersionUpgrade`
+ `ApplyImmediately` (festgelegt auf `true` oder `false`)
**Anmerkung**
Wenn Ihr Cluster Teil einer Aurora globalen Datenbank ist, unterscheidet sich das Verfahren des direkten Upgrades geringfügig. Sie rufen den Vorgang [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalClusterParameterGroup.html) statt `ModifyDBCluster` auf. Weitere Informationen finden Sie unter [In-Situ-Hauptversions-Upgrades für globale Datenbanken](#AuroraMySQL.Upgrading.GlobalDB).
## Wie sich direkte Upgrades auf die Parametergruppen für einen Cluster auswirken
Aurora-Parametergruppen haben verschiedene Sätze von Konfigurationseinstellungen für Cluster, die mit MySQL 5.7 oder 8.0 kompatibel sind. Wenn Sie ein direktes Upgrade durchführen, müssen der aktualisierte Cluster und alle seine Instances die entsprechenden Cluster- und Instance-Parametergruppen verwenden:
Ihr Cluster und Ihre Instances verwenden möglicherweise die standardmäßigen 5.7-kompatiblen Parametergruppen. In diesem Fall beginnen der aktualisierte Cluster und die Instance mit den standardmäßigen 8.0-kompatiblen Parametergruppen. Wenn Ihr Cluster und Ihre Instances benutzerdefinierte Parametergruppen verwenden, müssen Sie entsprechende oder 8.0-kompatible Parametergruppen erstellen. Diese müssen während des Upgrade-Vorgangs angegeben werden.
**Anmerkung**
Für die meisten Parametereinstellungen können Sie die benutzerdefinierte Parametergruppe an zwei Stellen auswählen. Und zwar können Sie sie auswählen, wenn Sie den Cluster erstellen oder wenn Sie die Parametergruppe später dem Cluster zuordnen.
Wenn Sie jedoch eine nicht standardmäßige Einstellung für den Parameter `lower_case_table_names` verwenden, müssen Sie die benutzerdefinierte Parametergruppe mit dieser Einstellung im Voraus einrichten. Geben Sie dann die Parametergruppe an, wenn Sie die Snapshot-Wiederherstellung zum Erstellen des Clusters durchführen. Änderungen des `lower_case_table_names`-Parameters haben keine Auswirkung, nachdem der Cluster erstellt wurde.
Wir empfehlen Ihnen, die gleiche Einstellung für `lower_case_table_names` zu verwenden, wenn Sie ein Upgrade von Aurora MySQL Version 2 auf Version 3 durchführen.
Bei einer globalen Aurora-Datenbank, die auf Aurora MySQL basiert, können Sie ein direktes Upgrade von Aurora-MySQL-Version 2 auf Version 3 nur durchführen, wenn Sie den `lower_case_table_names`-Parameter auf den Standardwert setzen und Ihre globale Datenbank neu starten. Weitere Informationen zu den möglichen Verfahren finden Sie unter [Hauptversions-Upgrades](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major).
## Änderungen an Cluster-Eigenschaften zwischen Aurora-MySQL-Versionen
Wenn Sie von Aurora-MySQL-Version 2 zu Version 3 aktualisieren, stellen Sie sicher, dass Sie alle Anwendungen oder Skripts ändern, die Sie zum Einrichten oder Verwalten von Clustern und DB-Instances von Aurora MySQL verwenden.
Ändern Sie außerdem Ihren Code, der Parametergruppen manipuliert, um der Tatsache Rechnung zu tragen, dass die Standardnamen der Parametergruppen für 5.7- und 8.0-kompatible Cluster unterschiedlich sind. Die entsprechenden Parametergruppennamen für Aurora-MySQL-Version 2 und 3-Cluster sind `default.aurora-mysql5.7` und `default.aurora-mysql8.0`.
Beispielsweise haben Sie möglicherweise Code wie den folgenden, der vor einem Upgrade für Ihren Cluster gilt.
```
# Check the default parameter values for MySQL 5.7–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql5.7 --region us-east-1
```
Ändern Sie nach dem Upgrade der Hauptversion des Clusters diesen Code wie folgt.
```
# Check the default parameter values for MySQL 8.0–compatible clusters.
aws rds describe-db-parameters --db-parameter-group-name default.aurora-mysql8.0 --region us-east-1
```
## In-Situ-Hauptversions-Upgrades für globale Datenbanken
Bei einer globalen Aurora-Datenbank aktualisieren Sie den globalen Datenbank-Cluster. Aurora aktualisiert automatisch alle Cluster gleichzeitig und stellt sicher, dass sie alle dieselbe Engine-Version ausführen. Diese Anforderung liegt darin begründet, dass Änderungen an Systemtabellen, Datendateiformaten usw. automatisch auf alle sekundären Cluster repliziert werden.
Folgen Sie den Anweisungen in [Funktionsweise des Aurora MySQL direkten Upgrade der Hauptversion](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence). Wenn Sie angeben, was aktualisiert werden soll, stellen Sie sicher, dass Sie den globalen Datenbank-Cluster anstelle eines der darin enthaltenen Cluster auswählen.
Wenn Sie die AWS-Managementkonsole verwenden, wählen Sie das Element mit der Rolle **Global database** (Globale Datenbank) aus.
![\[Aktualisieren globaler Datenbank-Cluster\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-major-upgrade-global-cluster.png)
Wenn Sie die AWS CLI oder die RDS-API verwenden, starten Sie den Upgrade-Prozess, indem Sie den Befehl [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) oder die Operation [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalCluster.html) aufrufen. Verwenden Sie diese anstelle von `modify-db-cluster` oder `ModifyDBCluster`.
**Anmerkung**
Sie können keine benutzerdefinierte Parametergruppe für den globalen Datenbank-Cluster angeben, während Sie ein größeres Versions-Upgrade dieser globalen Aurora-Datenbank durchführen. Erstellen Sie Ihre benutzerdefinierten Parametergruppen in jeder Region des globalen Clusters. Wenden Sie sie nach dem Upgrade manuell auf die regionalen Cluster an.
Um die Hauptversion eines globalen Datenbank-Clusters von Aurora MySQL mithilfe der AWS CLI zu aktualisieren, verwenden Sie den Befehl [modify-gobal-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) mit den folgenden erforderlichen Parametern:
+ `--global-cluster-identifier`
+ `--engine aurora-mysql`
+ `--engine-version`
+ `--allow-major-version-upgrade`
Im folgenden Beispiel wird der globale Datenbank-Cluster auf Aurora-MySQL-Version 3.04.2 aktualisiert.
**Example**
Für Linux, macOS oder Unix:
```
aws rds modify-global-cluster \
--global-cluster-identifier global_cluster_identifier \
--engine aurora-mysql \
--engine-version 8.0.mysql_aurora.3.04.2 \
--allow-major-version-upgrade
```
Für Windows:
```
aws rds modify-global-cluster ^
--global-cluster-identifier global_cluster_identifier ^
--engine aurora-mysql ^
--engine-version 8.0.mysql_aurora.3.04.2 ^
--allow-major-version-upgrade
```
## Direkte Upgrades für DB-Cluster mit regionsübergreifenden Lesereplikaten
Sie können einen Aurora-DB-Cluster, der über ein regionsübergreifendes Lesereplikat verfügt, mithilfe des direkten Upgrades aktualisieren, es gibt jedoch einige Überlegungen:
+ Sie müssen zuerst den Lesereplikat-DB-Cluster aktualisieren. Wenn Sie zuerst versuchen, den primären Cluster zu aktualisieren, erhalten Sie eine Fehlermeldung wie die folgende:
Unable to upgrade DB cluster test-xr-primary-cluster because the associated Aurora cross-Region replica test-xr-replica-cluster isn't patched yet. Upgrade the Aurora cross-Region replica and try again.
Das bedeutet, dass der primäre DB-Cluster keine höhere DB-Engine-Version als der Replikat-Cluster haben kann.
+ Bevor Sie den primären DB-Cluster aktualisieren, halten Sie den Schreib-Workload an und deaktivieren Sie alle neuen Verbindungsanfragen zur Schreiber-DB-Instance des primären Clusters.
+ Wenn Sie den primären Cluster aktualisieren, wählen Sie eine benutzerdefinierte DB-Cluster-Parametergruppe aus, bei der der `binlog_format`-Parameter auf einen Wert gesetzt ist, der die Replikation von Binärprotokollen unterstützt, z. B. `MIXED`.
Weitere Informationen zur Verwendung der binären Protokollierung mit Aurora MySQL finden Sie unter [Replizieren zwischen Aurora und MySQL oder zwischen Aurora und einem anderen Aurora-DB-Cluster (binäre Protokollreplikation)](AuroraMySQL.Replication.MySQL.md). Weitere Informationen zum Ändern der Aurora MySQL-Konfigurationsparameter finden Sie unter [Aurora MySQL Konfigurationsparameter](AuroraMySQL.Reference.ParameterGroups.md) und [Parametergruppen für Amazon Aurora](USER_WorkingWithParamGroups.md).
+ Warten Sie nicht lange mit dem Upgrade des primären DB-Clusters, nachdem Sie den Replikat-Cluster aktualisiert haben. Wir empfehlen, nicht länger als bis zum nächsten Wartungszeitraum zu warten.
+ Starten Sie nach dem Upgrade des primären DB-Clusters dessen Schreiber-DB-Instance neu. Die benutzerdefinierte DB-Cluster-Parametergruppe, die die Binlog-Replikation aktiviert, wird erst wirksam, wenn die Schreiber-DB-Instance neu gestartet wird.
+ Nehmen Sie den Schreib-Workload erst wieder auf oder aktivieren Sie Verbindungen zur Schreiber-DB-Instance, wenn Sie bestätigt haben, dass die regionsübergreifende Replikation neu gestartet wurde und dass die Replikatverzögerung in der sekundären AWS-Region 0 ist.
# Aurora MySQL direktes Upgrade
Die folgenden Linux-Beispiele zeigen, wie Sie die allgemeinen Schritte des Verfahrens für ein direktes Upgrade mit dem durchführen können AWS CLI.
In diesem ersten Beispiel wird ein Aurora-DB-Cluster erstellt, auf dem eine 2.x-Version von Aurora MySQL ausgeführt wird. Der Cluster enthält eine Writer-DB-Instance und eine Reader-DB-Instance Der Befehl `wait db-instance-available` pausiert, bis die Writer-DB-Instance verfügbar ist. Das ist der Punkt, an dem der Cluster für ein Upgrade bereit ist.
```
aws rds create-db-cluster --db-cluster-identifier mynewdbcluster --engine aurora-mysql \
--db-cluster-version 5.7.mysql_aurora.2.11.2
...
aws rds create-db-instance --db-instance-identifier mynewdbcluster-instance1 \
--db-cluster-identifier mynewdbcluster --db-instance-class db.t4g.medium --engine aurora-mysql
...
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
```
Die Aurora-MySQL-3.x-Versionen, auf die Sie den Cluster aktualisieren können, hängen von der 2.x-Version ab, auf der der Cluster derzeit läuft, sowie von der AWS-Region-Region, in der sich der Cluster befindet. Der erste Befehl mit `--output text` zeigt nur die verfügbare Zielversion an. Der zweite Befehl zeigt die vollständige JSON-Ausgabe der Antwort an. Diese Antwort enthält Details wie den `aurora-mysql`-Wert, den Sie für den `engine`-Parameter verwenden. Sie können auch sehen, dass ein Upgrade auf 3.04.0 ein Hauptversion-Upgrade darstellt.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.11.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.11.2 \
--query '*[].[ValidUpgradeTarget]'
...
{
"Engine": "aurora-mysql",
"EngineVersion": "8.0.mysql_aurora.3.04.0",
"Description": "Aurora MySQL 3.04.0 (compatible with MySQL 8.0.28)",
"AutoUpgrade": false,
"IsMajorVersionUpgrade": true,
"SupportedEngineModes": [
"provisioned"
],
"SupportsParallelQuery": true,
"SupportsGlobalDatabases": true,
"SupportsBabelfish": false,
"SupportsIntegrations": false
},
...
```
Dieses Beispiel zeigt, dass Aurora das Upgrade nicht durchführt, wenn Sie eine Zielversionsnummer eingeben, die kein gültiges Upgrade-Ziel für den Cluster ist. Aurora führt auch kein Hauptversions-Upgrade durch, es sei denn, Sie geben den Parameter `--allow-major-version-upgrade` an. Auf diese Weise können Sie nicht versehentlich ein Upgrade durchführen, das umfangreiche Tests und Änderungen an Ihrem Anwendungscode erfordert.
```
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 5.7.mysql_aurora.2.09.2 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: Cannot find upgrade target from 5.7.mysql_aurora.2.11.2 with requested version 5.7.mysql_aurora.2.09.2.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --region us-east-1 --apply-immediately
An error occurred (InvalidParameterCombination) when calling the ModifyDBCluster operation: The AllowMajorVersionUpgrade flag must be present when upgrading to a new major version.
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --apply-immediately --allow-major-version-upgrade
{
"DBClusterIdentifier": "mynewdbcluster",
"Status": "available",
"Engine": "aurora-mysql",
"EngineVersion": "5.7.mysql_aurora.2.11.2"
}
```
Es dauert einige Augenblicke, bis sich der Status des Clusters und der zugehörigen DB-Instances auf änder `upgrading`. Die Versionsnummern für die Cluster- und DB-Instances ändern sich erst, wenn das Upgrade abgeschlossen ist. Auch hier können Sie den `wait db-instance-available`-Befehl verwenden, damit die Writer-DB-Instance wartet, bis das Upgrade abgeschlossen ist, bevor Sie fortfahren.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[Status,EngineVersion]' --output text
upgrading 5.7.mysql_aurora.2.11.2
aws rds describe-db-instances --db-instance-identifier mynewdbcluster-instance1 \
--query '*[].{DBInstanceIdentifier:DBInstanceIdentifier,DBInstanceStatus:DBInstanceStatus} | [0]'
{
"DBInstanceIdentifier": "mynewdbcluster-instance1",
"DBInstanceStatus": "upgrading"
}
aws rds wait db-instance-available --db-instance-identifier mynewdbcluster-instance1
```
Zu diesem Zeitpunkt entspricht die Versionsnummer für den Cluster der Nummer, die für das Upgrade angegeben wurde.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[EngineVersion]' --output text
8.0.mysql_aurora.3.04.0
```
Das vorhergehende Beispiel führte ein sofortiges Upgrade durch Angabe des `--apply-immediately`-Parameters durch. Damit das Upgrade zu einem geeigneten Zeitpunkt durchgeführt wird, zu dem nicht zu erwarten ist, dass der Cluster ausgelastet ist, können Sie den Parameter `--no-apply-immediately` festlegen. Dadurch wird das Upgrade während des nächsten Wartungsfensters für den Cluster gestartet. Das Wartungsfenster definiert den Zeitraum, in dem Wartungsvorgänge beginnen können. Ein lang andauernder Vorgang kann während des Wartungsfensters möglicherweise nicht beendet werden. Daher müssen Sie kein größeres Wartungsfenster definieren, selbst wenn Sie davon ausgehen, dass das Upgrade sehr lange dauern kann.
Im folgenden Beispiel wird ein Cluster aktualisiert, auf dem ursprünglich Aurora-MySQL-Version 2.11.2 ausgeführt wurde. In der Ausgabe `describe-db-engine-versions` stellen die Werte `False` und `True` die Eigenschaft `IsMajorVersionUpgrade` dar. Ab Version 2.11.2 können Sie auf andere 2.\$1-Versionen aktualisieren. Diese Upgrades gelten nicht als Hauptversions-Upgrades und erfordern daher kein direktes Upgrade. Ein direktes Upgrade ist nur für die 3.\$1-Versionen verfügbar, die in der Liste aufgeführt sind.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].{EngineVersion:EngineVersion}' --output text
5.7.mysql_aurora.2.11.2
aws rds describe-db-engine-versions --engine aurora-mysql --engine-version 5.7.mysql_aurora.2.10.2 \
--query '*[].[ValidUpgradeTarget]|[0][0]|[*].[EngineVersion,IsMajorVersionUpgrade]' --output text
5.7.mysql_aurora.2.11.3 False
5.7.mysql_aurora.2.11.4 False
5.7.mysql_aurora.2.11.5 False
5.7.mysql_aurora.2.11.6 False
5.7.mysql_aurora.2.12.0 False
5.7.mysql_aurora.2.12.1 False
5.7.mysql_aurora.2.12.2 False
5.7.mysql_aurora.2.12.3 False
8.0.mysql_aurora.3.04.0 True
8.0.mysql_aurora.3.04.1 True
8.0.mysql_aurora.3.04.2 True
8.0.mysql_aurora.3.04.3 True
8.0.mysql_aurora.3.05.2 True
8.0.mysql_aurora.3.06.0 True
8.0.mysql_aurora.3.06.1 True
8.0.mysql_aurora.3.07.1 True
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster \
--engine-version 8.0.mysql_aurora.3.04.0 --no-apply-immediately --allow-major-version-upgrade
...
```
Wenn ein Cluster ohne ein festgelegtes Wartungsfenster erstellt wird, wählt Aurora einen zufälligen Wochentag aus. In diesem Fall wird der Befehl `modify-db-cluster` an einem Montag gesendet. Daher ändern wir das Wartungsfenster auf Dienstagmorgen. Alle Zeiten sind in der UTC-Zeitzone dargestellt. Das Fenster `tue:10:00-tue:10:30` entspricht 2:00 - 2:30 Uhr Pacific Time. Die Änderung des Wartungsfensters wird sofort wirksam.
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
[
"sat:08:20-sat:08:50"
]
]
aws rds modify-db-cluster --db-cluster-identifier mynewdbcluster --preferred-maintenance-window tue:10:00-tue:10:30"
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster --query '*[].[PreferredMaintenanceWindow]'
[
[
"tue:10:00-tue:10:30"
]
]
```
Das folgende Beispiel zeigt, wie ein Bericht über die durch das Upgrade generierten Ereignisse abgerufen wird. Das Argument `--duration` gibt die Anzahl der Minuten an, die für den Abruf der Ereignisinformationen erforderlich sind. Dieses Argument ist erforderlich, da `describe-events` standardmäßig nur Ereignisse der letzten Stunde ausgibt.
```
aws rds describe-events --source-type db-cluster --source-identifier mynewdbcluster --duration 20160
{
"Events": [
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "DB cluster created",
"EventCategories": [
"creation"
],
"Date": "2022-11-17T01:24:11.093000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Performing online pre-upgrade checks.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T22:57:08.450000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Performing offline pre-upgrade checks.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T22:57:59.519000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Creating pre-upgrade snapshot [preupgrade-mynewdbcluster-5-7-mysql-aurora-2-10-2-to-8-0-mysql-aurora-3-02-0-2022-11-18-22-55].",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:00:22.318000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Cloning volume.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:01:45.428000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:02:25.141000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Purging undo records for old row versions. Records remaining: 164",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:06:23.036000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Upgrade in progress: Upgrading database objects.",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:06:48.208000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
},
{
"SourceIdentifier": "mynewdbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster major version has been upgraded",
"EventCategories": [
"maintenance"
],
"Date": "2022-11-18T23:10:28.999000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mynewdbcluster"
}
]
}
```
# Finden der Gründe für Fehler bei Hauptversion-Upgrades von Aurora MySQL
Im [Tutorial](AuroraMySQL.Upgrading.Tutorial.md) wurde das Upgrade von Aurora-MySQL-Version 2 auf Version 3 erfolgreich abgeschlossen. Wenn das Upgrade jedoch fehlgeschlagen wäre, würden Sie wissen wollen, warum.
Sie können damit beginnen, den AWS CLI-Befehl `describe-events` zu verwenden, um sich die DB-Cluster-Ereignisse anzusehen. Dieses Beispiel zeigt die Ereignisse für `mydbcluster` der letzten 10 Stunden.
```
aws rds describe-events \
--source-type db-cluster \
--source-identifier mydbcluster \
--duration 600
```
In diesem Fall ist bei der Upgrade-Vorabprüfung ein Fehler aufgetreten.
```
{
"Events": [
{
"SourceIdentifier": "mydbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster engine version upgrade started.",
"EventCategories": [
"maintenance"
],
"Date": "2024-04-11T13:23:22.846000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
},
{
"SourceIdentifier": "mydbcluster",
"SourceType": "db-cluster",
"Message": "Database cluster is in a state that cannot be upgraded: Upgrade prechecks failed. For more details, see the
upgrade-prechecks.log file. For more information on troubleshooting the cause of the upgrade failure, see
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html",
"EventCategories": [
"maintenance"
],
"Date": "2024-04-11T13:23:24.373000+00:00",
"SourceArn": "arn:aws:rds:us-east-1:123456789012:cluster:mydbcluster"
}
]
}
```
Um die genaue Ursache des Problems zu diagnostizieren, untersuchen Sie die Datenbankprotokolle für die Schreiber-DB-Instance. Wenn ein Upgrade auf Aurora-MySQL-Version 3 fehlschlägt, enthält die Schreiber-Instance eine Protokolldatei namens `upgrade-prechecks.log`. Dieses Beispiel zeigt, wie Sie das Vorhandensein dieses Protokolls erkennen und es dann zur Untersuchung in eine lokale Datei herunterladen.
```
aws rds describe-db-log-files --db-instance-identifier mydbcluster-instance \
--query '*[].[LogFileName]' --output text
error/mysql-error-running.log
error/mysql-error-running.log.2024-04-11.20
error/mysql-error-running.log.2024-04-11.21
error/mysql-error.log
external/mysql-external.log
upgrade-prechecks.log
aws rds download-db-log-file-portion --db-instance-identifier mydbcluster-instance \
--log-file-name upgrade-prechecks.log \
--starting-token 0 \
--output text >upgrade_prechecks.log
```
Die `upgrade-prechecks.log`-Datei befindet sich im JSON-Format. Wir laden sie mit der Option `--output text` herunter, um JSON-Output nicht in einem anderen JSON-Wrapper zu kodieren. Für Upgrades auf Aurora-MySQL-Version 3 enthält dieses Protokoll immer bestimmte Informations- und Warnmeldungen. Es enthält nur Fehlermeldungen, wenn das Upgrade fehlschlägt. Wenn das Upgrade erfolgreich ist, wird die Protokolldatei überhaupt nicht erstellt.
Um alle Fehler zusammenzufassen und die zugehörigen Objekt- und Beschreibungsfelder anzuzeigen, können Sie den Befehl `grep -A 2 '"level": "Error"'` für den Inhalt der `upgrade-prechecks.log`-Datei ausführen. Dadurch werden jede Fehlerzeile und die beiden Zeilen danach angezeigt. Diese enthalten den Namen des entsprechenden Datenbankobjekts und Anleitungen zur Behebung des Problems.
```
$ cat upgrade-prechecks.log | grep -A 2 '"level": "Error"'
"level": "Error",
"dbObject": "problematic_upgrade.dangling_fulltext_index",
"description": "Table `problematic_upgrade.dangling_fulltext_index` contains dangling FULLTEXT index. Kindly recreate the table before upgrade."
```
In diesem Beispiel können Sie den folgenden SQL-Befehl für die problematische Tabelle ausführen, um das Problem zu beheben, oder Sie können die Tabelle ohne den hängenden Index neu erstellen.
```
OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;
```
Versuchen Sie anschließend das Upgrade erneut.
# Problembehandlung für Aurora MySQL direkte Upgrades
Verwenden Sie die folgenden Tipps, um Probleme mit direkten Aurora-MySQL-Upgrades zu beheben. Diese Tipps gelten nicht für Aurora Serverless-DB-Cluster.
| Grund für das abgebrochene oder langsame direkte Upgrade | Auswirkung | Lösung, die den Abschluss eines direkten Upgrades im Wartungsfenster ermöglicht |
| --- | --- | --- |
| Das zugehörige regionsübergreifende Aurora-Replikat wurde noch nicht gepatcht. | Aurora bricht das Upgrade ab. | Aktualisieren Sie das regionsübergreifende Aurora-Replikat und versuchen Sie es erneut. |
| Der Cluster hat XA-Transaktionen im vorbereiteten Zustand | Aurora bricht das Upgrade ab. | Bestätigen Sie alle vorbereiteten XA-Transaktionen oder setzen Sie sie zurück. |
| Der Cluster verarbeitet alle DDL-Anweisungen (Data Definition Language) | Aurora bricht das Upgrade ab. | Erwägen Sie, zu warten und das Upgrade durchzuführen, nachdem alle DDL-Anweisungen abgeschlossen sind. |
| Der Cluster hat für viele Zeilen nicht festgeschriebene Änderungen | Das Upgrade könnte eine lange Zeit dauern. | Der Upgrade-Prozess setzt die nicht festgeschriebenen Änderungen zurück. Der Indikator für diese Bedingung ist der Wert von `TRX_ROWS_MODIFIED` in der `INFORMATION_SCHEMA.INNODB_TRX`-Tabelle. Erwägen Sie, das Upgrade erst durchzuführen, nachdem alle großen Transaktionen festgeschrieben oder zurückgesetzt wurden. |
| Der Cluster hat eine hohe Anzahl von Undo-Datensätzen | Das Upgrade könnte eine lange Zeit dauern. | Selbst wenn sich die nicht festgeschrieben Transaktionen nicht auf eine große Anzahl von Zeilen auswirken, können sie eine große Datenmenge beinhalten. Beispielsweise könnten Sie große BLOBs einfügen. Aurora erkennt oder generiert ein Ereignis für diese Art von Transaktionsaktivität nicht automatisch. Der Indikator für diese Bedingung ist die Länge der Verlaufsliste (History List Length, HLL). Der Upgrade-Prozess setzt die nicht festgeschriebenen Änderungen zurück. Sie können die HLL in der Ausgabe des SQL-Befehls `SHOW ENGINE INNODB STATUS` oder direkt mit der folgenden SQL-Abfrage überprüfen: SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
Sie können auch die Metrik `RollbackSegmentHistoryListLength` in Amazon CloudWatch überwachen. Erwägen Sie, das Upgrade erst durchzuführen, wenn die HLL kleiner ist. |
| Der Cluster ist dabei, eine große binäre Protokoll-Transaktion festzuschreiben | Das Upgrade könnte eine lange Zeit dauern. | Der Upgrade-Prozess wartet, bis die binären Protokolländerungen angewendet werden. In diesem Zeitraum können mehr Transaktionen oder DDL-Anweisungen gestartet werden, was den Upgrade-Prozess weiter verlangsamt. Planen Sie den Upgrade-Prozess, wenn der Cluster nicht mit der Generierung von Änderungen der binären Protokollreplikation beschäftigt Aurora erkennt oder generiert ein Ereignis für diese Bedingung nicht automatisch. |
| Schemainkonsistenzen, die auf das Entfernen oder die Beschädigung von Dateien zurückzuführen sind | Aurora bricht das Upgrade ab. | Ändern Sie die Standard-Speicher-Engine für temporäre Tabellen von MyISAM auf InnoDB. Führen Sie die folgenden Schritte aus: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html) |
| Der Master-Benutzer wurde gelöscht. | Aurora bricht das Upgrade ab. | Löschen Sie den Master-Benutzer nicht. Sollten Sie jedoch aus irgendeinem Grund den Master-Benutzer löschen, stellen Sie ihn mithilfe der folgenden SQL-Befehle wieder her: CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES,
LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT,
TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;
|
Weitere Informationen zur Behebung von Problemen, die dazu führen, dass Upgrade-Vorabprüfungen fehlschlagen, finden Sie in den folgenden Blogs:
+ [Checkliste für das Upgrade von Amazon-Aurora-MySQL-Version 2 (mit MySQL-5.7-Kompatibilität) auf Version 3 (mit MySQL-8.0-Kompatibilität), Teil 1](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-1/)
+ [Checkliste für das Upgrade von Amazon-Aurora-MySQL-Version 2 (mit MySQL-5.7-Kompatibilität) auf Version 3 (mit MySQL-8.0-Kompatibilität), Teil 2](https://aws.amazon.com/blogs/database/amazon-aurora-mysql-version-2-with-mysql-5-7-compatibility-to-version-3-with-mysql-8-0-compatibility-upgrade-checklist-part-2/)
Sie können die folgenden Schritte verwenden, um eigene Überprüfungen für einige der Bedingungen in der vorherigen Tabelle durchzuführen. Auf diese Weise können Sie das Upgrade für einen Zeitpunkt planen, an dem Sie wissen, dass sich die Datenbank in einem Zustand befindet, in dem das Upgrade erfolgreich und schnell abgeschlossen werden kann.
+ Sie können nach offenen XA-Transaktionen suchen, indem Sie die `XA RECOVER`-Anweisung ausführen. Sie können dann die XA-Transaktionen festschreiben oder zurücksetzen, bevor Sie mit dem Upgrade beginnen.
+ Sie können nach DDL-Anweisungen suchen, indem Sie eine `SHOW PROCESSLIST` Anweisung ausführen und in der Ausgabe nach `CREATE`, `DROP`, `ALTER`, `RENAME` und `TRUNCATE` Anweisungen suchen. Warten Sie bis alle DDL-Anweisungen fertig sind, bevor Sie mit dem Upgrade beginnen.
+ Sie können die Gesamtzahl der nicht festgeschriebenen Zeilen überprüfen, indem Sie die `INFORMATION_SCHEMA.INNODB_TRX`-Tabelle abfragen. Die Tabelle enthält eine Zeile für jede Transaktion. Die `TRX_ROWS_MODIFIED` Spalte enthält die Anzahl der Zeilen, die von der Transaktion geändert oder eingefügt wurden.
+ Sie können die Länge der InnoDB-Verlaufsliste überprüfen, indem Sie die `SHOW ENGINE INNODB STATUS SQL`-Anweisung ausführen und nach `History list length` in der Ausgabe suchen. Sie können den Wert auch direkt überprüfen, indem Sie die folgende Abfrage ausführen:
```
SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
```
Die Länge der Verlaufsliste entspricht der Menge der Undo-Daten, die von der Datenbank gespeichert werden, um die Multi-Versions-Concurrency Control (MVCC) zu implementieren.
# Bereinigung nach dem Upgrade für Aurora MySQL Version 3
Nachdem Sie ein Upgrade von Aurora-MySQL-Clustern der 2 auf Aurora-MySQL-Version 3 abgeschlossen haben, können Sie diese anderen Bereinigungsaktionen ausführen:
+ Erstellen Sie neue MySQL 8.0-kompatible Versionen beliebiger benutzerdefinierter Parametergruppen. Wenden Sie alle erforderlichen benutzerdefinierten Parameterwerte auf die neuen Parametergruppen an.
+ Aktualisieren Sie alle CloudWatch-Alarme, Setup-Skripte usw., um die neuen Namen für alle Metriken zu verwenden, deren Namen von inklusiven Sprachänderungen betroffen waren. Eine Liste der -Metriken finden Sie unter [Inklusive Sprachänderungen für Aurora MySQL Version 3](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language).
+ Aktualisieren Sie alleCloudFormationVorlagen, um die neuen Namen für alle Konfigurationsparameter zu verwenden, deren Namen von inklusiven Sprachänderungen betroffen waren. Eine vollständige Liste der Parameter finden Sie unter [Inklusive Sprachänderungen für Aurora MySQL Version 3](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language).
## SPATIAL-Index
Überprüfen Sie nach dem Upgrade auf Aurora MySQL Version 3, ob Sie Objekte und Indizes im Zusammenhang mit räumlichen Indizes löschen oder neu erstellen müssen. Vor MySQL 8.0 konnte Aurora räumliche Abfragen mithilfe von Indizes optimieren, die keinen räumlichen Ressourcenbezeichner (SRID) enthielten. Aurora MySQL Version 3 verwendet nur räumliche Indizes, die SRIDs enthalten. Während eines Upgrades legt Aurora automatisch alle räumlichen Indizes ohne SRIDs ab und gibt Warnmeldungen im Datenbankprotokoll aus. Wenn Sie solche Warnmeldungen beobachten, erstellen Sie nach dem Upgrade neue räumliche Indizes mit SRIDs. Weitere Informationen zu Änderungen an räumlichen Funktionen und Datentypen in MySQL 8.0 finden Sie unter [Änderungen in MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html) im *MySQL-Referenzhandbuch*.
# Datenbank-Engine-Updates und -Korrekturen für Amazon Aurora MySQL
In den *Versionshinweisen für Amazon Aurora MySQL-Compatible Edition* finden Sie folgende Informationen:
+ [Aktualisierungen der Datenbank-Engine für Amazon-Aurora-MySQL-Version 3](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.30Updates.html)
+ [Aktualisierungen der Datenbank-Engine für Amazon-Aurora-MySQL-Version 2](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.20Updates.html)
+ [Aktualisierungen der Datenbank-Engine für Amazon-Aurora-MySQL-Version 1 (veraltet)](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.11Updates.html)
+ [MySQL-Bugfixes durch Updates der Datenbank-Engine von Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.Updates.MySQLBugs.html)
+ [In Amazon Aurora MySQL behobene Sicherheitsschwachstellen](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraMySQLReleaseNotes/AuroraMySQL.CVE_list.html)