' for the table to apply all the pending DDL updates. Then try the upgrade again."
}
]
}
```
預先檢查會報告資料表 `test.test` 有待定的快速 DDL 操作。
若要允許繼續升級，您可以重建資料表，然後重試升級。
在重建資料表空間之前，請參閱 MySQL 文件中的[線上 DDL 操作](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html)，以了解鎖定和資料移動對前景交易的影響。
```
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)
```
重建資料表後，預先檢查會成功。
```
{
"id": "auroraFODUpgradeCheck",
"title": "Check for artifacts related to Aurora fast DDL feature",
"status": "OK",
"detectedProblems": []
}
```
**auroraGetDanglingFulltextIndex**
**預先檢查層級：錯誤**
**具有懸置 `FULLTEXT` 索引參考的資料表**
在 MySQL 5.6.26 之前，捨棄全文搜尋索引後，隱藏的 `FTS_DOC_ID` 和 `FTS_DOC_ID_INDEX` 資料欄可能會變得孤立。如需詳細資訊，請參閱[錯誤 \$176012](https://bugs.mysql.com/bug.php?id=76012)。
如果您在發生這種情況的舊版 MySQL 上建立任何資料表，可能會導致升級至 Aurora MySQL 第 3 版失敗。此預先檢查會確認資料庫叢集上沒有此類孤立或「懸置」的全文索引，然後再升級至 MySQL 8.0。如果此預先檢查失敗，請重建包含此類懸置全文索引的任何資料表。
**輸出範例：**
```
{
"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."
}
]
},
```
預先檢查會報告 `test.table_with_fts_index` 資料表的錯誤，因為它包含懸置的全文索引。若要允許繼續升級，請重建資料表以清除全文索引輔助資料表。使用 `OPTIMIZE TABLE test.table_with_fts_index` 或 `ALTER TABLE test.table_with_fts_index, ENGINE=INNODB`。
重建資料表後，預先檢查會通過。
```
{
"id": "auroraGetDanglingFulltextIndex",
"title": "Tables with dangling FULLTEXT index reference",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForDatafilePathInconsistency**
**預先檢查層級：錯誤**
**檢查與 `ibd` 檔案路徑相關的不一致**
此預先檢查僅適用於 Aurora MySQL 3.03.0 版及更低版本。如果此預先檢查發生錯誤，請升級至 Aurora MySQL 3.04 版或更新版本。
**輸出範例：**
```
{
"id": "auroraUpgradeCheckForDatafilePathInconsistency",
"title": "Check for inconsistency related to ibd file path.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForFtsSpaceIdZero**
**預先檢查層級：錯誤**
**檢查空間 ID 為零的全文索引**
在 MySQL 中，當您將[全文索引](https://dev.mysql.com/doc/refman/5.7/en/innodb-fulltext-index.html)新增至 InnoDB 資料表時，會建立多個輔助索引資料表空間。由於舊版 MySQL 在 5.6.20 版中修正的[錯誤](https://bugs.mysql.com/bug.php?id=72132)，這些輔助索引資料表可能在[系統資料表空間](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_system_tablespace)中建立，而不是在自己的 InnoDB 資料表空間中建立。
如果有任何此類輔助資料表空間存在，升級將會失敗。重新建立預先檢查錯誤中提及的全文索引，然後重試升級。
**輸出範例：**
```
{
"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."
}
]
},
```
預先檢查會報告 `test.fts_space_zero_check` 資料表的錯誤，因為它在系統資料表空間中有輔助全文搜尋 (FTS) 資料表。
在您捨棄並重新建立與此資料表相關聯的 FTS 索引後，預先檢查會成功。
在重建資料表空間之前，請參閱 MySQL 文件中的[分割操作](https://dev.mysql.com/doc/refman/5.7/en/innodb-online-ddl-operations.html#online-ddl-partitioning)，以了解鎖定和資料移動對前景交易的影響。
```
{
"id": "auroraUpgradeCheckForFtsSpaceIdZero",
"title": "Check for fulltext index with space id as zero",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForIncompleteXATransactions**
**預先檢查層級：錯誤**
**檢查 XA 交易是否處於預備狀態**
執行主要版本升級程序時，Aurora MySQL 第 2 版資料庫執行個體必須進行[正常關閉](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown)。這可確保所有交易都已遞交或復原，而且 InnoDB 已清除所有復原日誌記錄。由於交易復原是必要的，如果您的資料庫有任何 [XA 交易](https://dev.mysql.com/doc/refman/5.7/en/xa.html)處於預備狀態，它可能會封鎖正常關閉，使其無法繼續。因此，如果偵測到任何預備 XA 交易，在您採取動作遞交或復原之前，升級將無法繼續。
如需使用 `XA RECOVER` 尋找處於預備狀態的 XA 交易的詳細資訊，請參閱 MySQL 文件中的 [XA 交易 SQL 陳述式](https://dev.mysql.com/doc/refman/5.7/en/xa-statements.html)。如需 XA 交易狀態的詳細資訊，請參閱 MySQL 文件中的 [XA 交易狀態](https://dev.mysql.com/doc/refman/5.7/en/xa-states.html)。
**輸出範例：**
```
{
"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."
}
]
}
```
此預先檢查會報告錯誤，因為有交易處於預備狀態，應遞交或復原。
登入資料庫後，您可以檢查 [information\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html) 資料表和 `XA RECOVER` 輸出以取得詳細資訊。
在遞交或復原交易之前，我們建議您檢閱 [MySQL 文件](https://dev.mysql.com/doc/refman/5.7/en/xa-restrictions.html)和應用程式需求。
```
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)
```
在這種情況下，我們會復原預備交易。
```
mysql> XA ROLLBACK 'xatest';
Query OK, 0 rows affected (0.00 sec)
v
mysql> xa recover;
Empty set (0.00 sec)
```
在復原 XA 交易之後，預先檢查會成功。
```
{
"id": "auroraUpgradeCheckForIncompleteXATransactions",
"title": "Pre-checks for XA Transactions in prepared state.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForInstanceLimit**
**預先檢查層級：錯誤**
**檢查目前執行個體類別是否支援升級**
目前不支援從寫入器[資料庫執行個體類別](Concepts.DBInstanceClass.md)為 db.r6i.32xlarge 的 Aurora MySQL 2.12.0 或 2.12.1 版執行就地升級。在這種情況下，預先檢查會傳回錯誤。若要允許繼續升級，您可以將資料庫執行個體類別變更為 db.r6i.24xlarge 或更小。或者，您可以升級至 Aurora MySQL 2.12.2 版或更新版本，其中 db.r6i.32xlarge 支援就地升級至 Aurora MySQL 第 3 版。
**輸出範例：**
```
{
"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."
}
]
},
```
預先檢查會傳回錯誤，因為寫入器資料庫執行個體正在使用 db.r6i.32xlarge 執行個體類別，且正在 Aurora MySQL 2.12.1 版上執行。
**auroraUpgradeCheckForInternalUsers**
**預先檢查層級：錯誤**
**檢查 8.0 內部使用者**
此預先檢查僅適用於 Aurora MySQL 3.03.0 版及更低版本。如果此預先檢查發生錯誤，請升級至 Aurora MySQL 3.04 版或更新版本。
**輸出範例：**
```
{
"id": "auroraUpgradeCheckForInternalUsers",
"title": "Check for 8.0 internal users.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForInvalidUtf8mb3CharacterStringInViews**
**預先檢查層級：錯誤**
**檢查檢視定義中是否有無效的 utf8mb3 字元**
此預先檢查可識別包含無效 `utf8mb3` 字元編碼註解的檢視。在 MySQL 8.0 中，更嚴格的驗證會套用至中繼資料中的字元編碼，包括檢視註解。如果任何檢視定義包含 `utf8mb3` 字元集中無效的字元，升級會失敗。
若要解決此問題，請修改檢視定義以移除或取代任何非 BMP 字元，然後再嘗試升級。
**輸出範例：**
```
{
"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."
}
]
},
```
預先檢查會報告 `utf8mb3_invalid_char_view` 檢視定義在其定義中包含無效的 `utf8mb3` 字元。
若要解決此問題，請識別包含不支援字元的檢視，並更新註解。首先，檢查檢視結構並識別註解。
```
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)
```
識別包含錯誤的檢視後，請將檢視取代為 `CREATE OR REPLACE VIEW` 陳述式。
```
MySQL> CREATE OR REPLACE VIEW precheck.utf8mb3_invalid_char_view AS select 'This view definition to not use non-BMP characters' AS message;
```
更新包含不支援字元的所有檢視定義後，預先檢查會通過，且升級可以繼續進行。
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForInvalidUtf8mb3ColumnComments**
**預先檢查層級：錯誤**
**檢查 utf8mb3 資料欄註解是否無效**
此預先檢查會識別包含含有無效 `utf8mb3` 字元編碼之資料欄註解的資料表。在 MySQL 8.0 中，更嚴格的驗證會套用至中繼資料中的字元編碼，包括資料欄註解。如果任何資料欄註解包含 utf8mb3 字元集中無效的字元，升級將會失敗。
若要解決此問題，您必須在嘗試升級之前修改資料欄註解，以移除或取代任何非 BMP 字元。您可以使用 `ALTER TABLE` 陳述式來更新資料欄註解。
**輸出範例：**
```
{
"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."
}
]
}
```
預先檢查會報告 `test.t2` 資料表在一或多個資料欄註解中包含無效的 `utf8mb3` 字元，特別是因為存在非 BMP 字元。
若要解決此問題，您可以識別有問題的資料欄並更新其註解。首先，檢查資料表結構以識別具有註解的資料欄：
```
mysql> SHOW CREATE TABLE test.t2\G
```
使用有問題的註解識別資料欄後，請使用 `ALTER TABLE` 陳述式更新資料欄。例如：
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT 'Updated comment without non-BMP characters';
```
或者，您可以完全移除註解：
```
mysql> ALTER TABLE test.t2 MODIFY COLUMN column_name data_type COMMENT '';
```
更新所有有問題的資料欄註解後，預先檢查將會通過，而且升級可以繼續：
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3ColumnComments",
"title": "Check for invalid utf8mb3 column comments.",
"status": "OK",
"detectedProblems": []
}
```
修改資料欄註解之前，請確定任何依賴這些註解的應用程式程式碼或文件都會隨之更新。如果您的應用程式需要非 BMP 字元，請考慮遷移至 utf8mb4 字元集，以獲得更好的 Unicode 支援。
**auroraUpgradeCheckForInvalidUtf8mb3IndexComments**
**預先檢查層級：錯誤**
**檢查 utf8mb3 索引註解是否無效**
此預先檢查會識別包含索引註解且 `utf8mb3` 字元編碼無效之資料表。在 MySQL 8.0 中，更嚴格的驗證會套用至中繼資料中的字元編碼，包括索引註解。如果任何索引註解包含字元集中無效的 `utf8mb3` 字元，升級會失敗。
若要解決此問題，您必須在嘗試升級之前修改索引註解，以移除或取代任何非 BMP 字元。
**輸出範例：**
```
{
"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."
}
]
},
```
預先檢查會報告 `utf8mb3_tab_index_comment` 資料表在一或多個資料欄註解中包含無效的 `utf8mb3` 字元，特別是因為存在非 BMP 字元。
若要解決此問題，請先檢查資料表結構，以識別包含有問題註解的索引。
```
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)
```
識別包含使用不支援字元之註解的索引後，請捨棄並重新建立索引。
捨棄和重新建立資料表索引可能會導致停機時間。建議您在維護期間規劃並排程此操作。
```
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);
```
下列範例顯示重新建立索引的另一種方式。
```
MySQL> ALTER TABLE utf8mb3_tab_index_comment DROP INDEX idx_name, ADD INDEX idx_name (name) COMMENT 'Updated comment without non-BMP characters';
```
在您移除或更新所有不支援的索引註解後，預先檢查會通過，且升級可以繼續進行。
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3IndexComments",
"title": "Check for invalid utf8mb3 index comments.",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForInvalidUtf8mb3TableComments**
**預先檢查層級：錯誤**
**檢查資料表定義中是否有無效的 utf8mb3 字元**
此預先檢查可識別包含無效 `utf8mb3` 字元編碼註解的資料表。在 MySQL 8.0 中，更嚴格的驗證會套用至中繼資料中的字元編碼，包括資料表註解。如果任何資料表註解包含字元集中無效的 `utf8mb3` 字元，升級會失敗。
若要解決此問題，您必須在嘗試升級之前修改資料表註解，以移除或取代任何非 BMP 字元。
**輸出範例：**
```
{
"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."
}
]
},
```
預先檢查會報告測試資料庫中 `utf8mb3_table_with_comment` 資料表定義的無效 `utf8mb3` 註解。
若要解決此問題，請識別包含不支援字元的資料表，並更新註解。首先，檢查資料表結構並識別註解。
```
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)
```
識別包含不支援聊天程式的資料表註解後，請使用 `ALTER TABLE` 陳述式更新註解。
```
MySQL> ALTER TABLE precheck.utf8mb3_table_with_comment COMMENT='Updated comment without non-BMP characters';
```
或者，您可以移除該註解。
```
MySQL> ALTER TABLE precheck.utf8mb3_table_with_comment COMMENT='';
```
從所有資料表註解中移除所有不支援的字元後，預先檢查會成功。
```
{
"id": "auroraUpgradeCheckForInvalidUtf8mb3TableComments",
"title": "Check for invalid utf8mb3 table comments.",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForMasterUser**
**預先檢查層級：錯誤**
**檢查 RDS 主要使用者是否存在**
MySQL 8 已新增支援[角色](https://dev.mysql.com/doc/refman/8.0/en/roles.html)和[動態權限](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#static-dynamic-privileges)的新權限模型，讓權限管理更容易且更精細。作為此變更的一部分，Aurora MySQL 推出了新的 `rds_superuser_role`，在從 Aurora MySQL 第 2 版升級至第 3 版時，會自動授予資料庫的主要使用者。
如需 Aurora MySQL 中指派給主要使用者的角色和權限的詳細資訊，請參閱 [主要使用者帳戶權限](UsingWithRDS.MasterAccounts.md)。如需 Aurora MySQL 第 3 版中角色型權限模型的詳細資訊，請參閱 [角色型權限模型](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model)。
此預先檢查會確認主要使用者是否存在於資料庫中。如果主要使用者不存在，預先檢查會失敗。若要允許繼續升級，請重設主要使用者密碼或手動建立使用者，以重新建立主要使用者。然後重試升級。如需重設主要使用者密碼的詳細資訊，請參閱 [變更資料庫主要使用者的密碼](Aurora.Modifying.md#Aurora.Modifying.Password)。
**輸出範例：**
```
{
"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 '%'"
}
]
}
```
重設主要使用者密碼後，預先檢查將會通過，而且您可以重試升級。
下列範例使用 AWS CLI 重設密碼。密碼變更會立即套用。
```
aws rds modify-db-cluster \
--db-cluster-identifier my-db-cluster \
--master-user-password my-new-password
```
然後，預先檢查成功。
```
{
"id": "auroraUpgradeCheckForMasterUser",
title": "Check if master user exists",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForPrefixIndexOnGeometryColumns**
**預先檢查層級：錯誤**
**檢查字首索引上的幾何資料欄**
從 [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) 開始，您無法再使用[幾何](https://dev.mysql.com/doc/refman/5.7/en/gis-data-formats.html)資料類型在資料欄上建立[字首](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix)索引。如需詳細資訊，請參閱 [WL\$111808](https://dev.mysql.com/worklog/task/?id=11808)。
如果有任何此類索引存在，您的升級將會失敗。若要解決此問題，請在預先檢查失敗時提及的資料表上捨棄字首 `GEOMETRY` 索引。
**輸出範例：**
```
{
"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`;"
}
]
}
```
預先檢查會報告錯誤，因為 `test.geom_index_prefix` 資料表包含 `GEOMETRY` 欄上有字首的索引。
捨棄此索引後，預先檢查會成功。
```
{
"id": "auroraUpgradeCheckForPrefixIndexOnGeometryColumns",
"title": "Check for geometry columns on prefix indexs",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForSpecialCharactersInProcedures**
**預先檢查層級：錯誤**
**檢查預存程序中與特殊字元相關的不一致**
在 MySQL 8.0 之前，資料庫名稱、資料表名稱和其他物件會對應至資料目錄中的檔案，也就是檔案型中繼資料。在升級至 MySQL 8.0 的過程中，所有資料庫物件都會遷移至存放在 `mysql` 結構描述中的新內部資料字典資料表，以支援新實作的[單元資料字典](https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html)。在遷移預存程序的過程中，系統會驗證每個程序的程序定義和本文，因為它會擷取到新的資料字典中。
在 MySQL 8 之前，在某些情況下，可以建立預存常式，或直接插入 `mysql.proc` 資料表中包含特殊字元的程序。例如，您可以建立預存程序，其中包含不合規、[非中斷空格字元](https://en.wikipedia.org/wiki/Non-breaking_space) `\xa0` 的註解。如果遇到任何此類程序，升級會失敗。
此預先檢查會驗證預存程序的本文和定義不包含任何此類字元。若要允許繼續升級，請重新建立這些預存程序，而不含任何隱藏或特殊字元。
**輸出範例：**
```
{
"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."
}
]
}
```
預先檢查會報告資料庫叢集包含 `get_version_proc` 資料庫中名為 `test` 的程序，其中包含程序本文中的特殊字元。
捨棄並重新建立預存程序後，預先檢查會成功，讓升級繼續進行。
```
{
"id": "auroraUpgradeCheckForSpecialCharactersInProcedures",
"title": "Check for inconsistency related to special characters in stored procedures.",
"status": "OK",
"detectedProblems": []
},
```
**auroraUpgradeCheckForSysSchemaObjectTypeMismatch**
**預先檢查層級：錯誤**
**檢查 `sys` 結構描述的物件類型不符**
[sys 結構描述](https://dev.mysql.com/doc/refman/8.0/en/sys-schema.html)是 MySQL 資料庫中的一組物件和檢視，可協助使用者故障診斷、最佳化和監控其資料庫執行個體。從 Aurora MySQL 第 2 版升級至第 3 版時，`sys` 結構描述檢視會重新建立並更新為新的 Aurora MySQL 第 3 版定義。
在升級過程中，如果 `sys` 結構描述中的任何物件是使用儲存引擎 ([INFORMATION\$1SCHEMA.TABLES](https://dev.mysql.com/doc/refman/5.7/en/information-schema-tables-table.html) 中的`sys_config/BASE TABLE`) 而非檢視來定義，則升級將會失敗。您可以在 `information_schema.tables` 資料表中找到此類資料表。這不是預期的行為，但在某些情況下，可能會因使用者錯誤而發生。
此預先檢查會驗證所有 `sys` 結構描述物件，以確保它們使用正確的資料表定義，且檢視不會錯誤地定義為 InnoDB 或 MyISAM 資料表。若要解決問題，請重新命名或捨棄任何傳回的物件，以手動修正這些物件。然後重試升級。
**輸出範例：**
```
{
"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). "
}
]
}
```
預先檢查會報告 `sys` 結構描述中的 [sys.waits\$1global\$1by\$1latency](https://dev.mysql.com/doc/refman/5.7/en/sys-waits-global-by-latency.html) 檢視的類型不符，導致無法繼續升級。
登入資料庫執行個體後，您可以看到此物件在應該是檢視時定義為 InnoDB 資料表。
```
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)
```
若要解決此問題，我們可以捨棄並重新建立具有[正確定義](https://github.com/mysql/mysql-server/blob/mysql-5.7.44/scripts/sys_schema/views/p_s/waits_global_by_latency.sql)的檢視，或將其重新命名。在升級過程中，系統會自動使用正確的資料表定義建立它。
```
mysql> RENAME TABLE sys.waits_global_by_latency to sys.waits_global_by_latency_old;
Query OK, 0 rows affected (0.01 sec)
```
執行此操作後，預先檢查會通過。
```
{
"id": "auroraUpgradeCheckForSysSchemaObjectTypeMismatch",
"title": "Check object type mismatch for sys schema.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckForViewColumnNameLength**
**預先檢查層級：錯誤**
**檢查檢視中資料欄名稱的上限**
MySQL 中[允許的資料欄名稱長度上限](https://dev.mysql.com/doc/refman/5.7/en/identifier-length.html)為 64 個字元。在 MySQL 8.0 之前，在某些情況下，可以建立資料欄名稱大於 64 個字元的檢視。如果您的資料庫執行個體上存在任何此類檢視，則會傳回預先檢查錯誤，且升級將會失敗。若要允許繼續升級，您必須重新建立有問題的檢視，確保其資料欄長度小於 64 個字元。然後重試升級。
**輸出範例：**
```
{
"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."
}
]
}
```
預先檢查會報告 `test.colname_view_test` 檢視包含的資料欄 `col2_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad_pad` 超過允許的資料欄長度上限 64 個字元。
查看檢視定義，我們可以看到違規的資料欄。
```
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)
```
若要允許繼續升級，請重新建立檢視，確保資料欄長度不超過 64 個字元。
```
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)
```
執行此操作後，預先檢查會成功。
```
{
"id": "auroraUpgradeCheckForViewColumnNameLength",
"title": "Check for upperbound limit related to column name in view.",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckIndexLengthLimitOnTinyColumns**
**預先檢查層級：錯誤**
**檢查在小型資料欄上定義字首長度大於 255 個位元組之索引的資料表**
在 MySQL 中使用[二進位資料類型](https://dev.mysql.com/doc/refman/5.7/en/binary-varbinary.html)在資料欄上建立索引時，您必須在索引定義中新增[字首](https://dev.mysql.com/doc/refman/5.7/en/column-indexes.html#column-indexes-prefix)長度。在 MySQL 8.0 之前，在某些情況下，您可以指定大於此類資料類型所允許大小上限的字首長度。例如 `TINYTEXT` 和 `TINYBLOB` 欄，其中允許的資料大小上限為 255 個位元組，但允許大於此值的索引字首。如需詳細資訊，請參閱 MySQL 文件中的 [InnoDB 限制](https://dev.mysql.com/doc/refman/8.0/en/innodb-limits.html)。
如果此預先檢查失敗，請捨棄違規的索引，或將索引的 `TINYTEXT` 和 `TINYBLOB` 欄的字首長度減少到少於 255 個位元組。然後重試升級。
**輸出範例：**
```
{
"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."
}
]
}
```
預先檢查會報告 `test.tintxt_prefixed_index` 資料表的錯誤，因為其索引 `PRIMARY` 的字首在 TINYTEXT 或 TINYBLOB 資料欄上大於 255 個位元組。
查看此資料表的定義，我們可以看到主索引鍵在 `TINYTEXT` 資料欄 `col1` 上有 65 的字首。由於資料表是使用 `utf8mb4` 字元集來定義，每個字元可存放 4 個位元組，因此字首超過 255 個位元組的限制。
```
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)
```
使用 `utf8mb4` 字元集將索引字首修改為 63 將允許繼續升級。
```
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
```
執行此操作後，預先檢查會成功。
```
{
"id": "auroraUpgradeCheckIndexLengthLimitOnTinyColumns",
"title": "Check for the tables with indexes defined with prefix length greater than 255 bytes on tiny columns",
"status": "OK",
"detectedProblems": []
}
```
**auroraUpgradeCheckMissingInnodbMetadataForMysqlHostTable**
**預先檢查層級：錯誤**
**檢查 `mysql.host` 資料表缺少的 InnoDB 中繼資料不一致**
這是 RDS 服務執行的僅限內部預先檢查。升級時會自動處理任何錯誤，並且可以安全地忽略。
如果您在此預先檢查中遇到任何錯誤，請向 [AWS Support](https://aws.amazon.com/support) 開立案例，以請求解決中繼資料不一致的問題。或者，您可以執行邏輯傾印，然後還原至新的 Aurora MySQL 第 3 版資料庫叢集，以重試升級。
## 警告
下列預先檢查會在預先檢查失敗時產生警告，但升級可以繼續。
**Topics**
+ [報告警告的 MySQL 預先檢查](#precheck-descriptions-warnings.mysql)
+ [報告警告的 Aurora MySQL 預先檢查](#precheck-descriptions-warnings.aurora)
### 報告警告的 MySQL 預先檢查
下列預先檢查來自 Community MySQL：
+ [defaultAuthenticationPlugin](#defaultAuthenticationPlugin)
+ [maxdbFlagCheck](#maxdbFlagCheck)
+ [mysqlDollarSignNameCheck](#mysqlDollarSignNameCheck)
+ [reservedKeywordsCheck](#reservedKeywordsCheck)
+ [utf8mb3Check](#utf8mb3Check)
+ [zeroDatesCheck](#zeroDatesCheck)
**defaultAuthenticationPlugin**
**預先檢查層級：警告**
**新的預設身分驗證外掛程式考量**
在 MySQL 8.0 中，引進了 `caching_sha2_password` 身分驗證外掛程式，提供比已棄用 `mysql_native_password` 外掛程式更安全的密碼加密和更好的效能。對於 Aurora MySQL 第 3 版，用於資料庫使用者的預設身分驗證外掛程式是 `mysql_native_password` 外掛程式。
此預先檢查會警告將會移除此外掛程式，並在未來的主要版本發行中變更預設值。在此變更之前，請考慮評估應用程式用戶端和使用者的相容性。
如需詳細資訊，請參閱 MySQL 文件中的 [caching\$1sha2\$1password 相容性問題和解決方案](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html#upgrade-caching-sha2-password-compatibility-issues)。
**輸出範例：**
```
{
"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**
**預先檢查層級：警告**
**使用過時的 `MAXDB` `sql_mode` 旗標**
在 MySQL 8.0 中，[移除](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html)了一些已棄用的 [sql\$1mode](https://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_sql_mode) 系統變數選項，其中一個是 `MAXDB`。此預先檢查會檢查所有目前連線的工作階段，以及常式和觸發條件，以確保沒有任何 `sql_mode` 設定為任何包含 `MAXDB` 的組合。
**輸出範例：**
```
{
"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"
}
]
}
```
預先檢查會報告 `test.maxdb_stored_routine` 常式包含不支援的 `sql_mode` 選項。
登入資料庫後，您可以在 `sql_mode` 包含 `MAXDB` 的常式定義中看到。
```
> SHOW CREATE PROCEDURE test.maxdb_stored_routine\G
*************************** 1. row ***************************
Procedure: maxdb_stored_routine
sql_mode: PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,MAXDB,NO_KEY_OPTIONS,NO_TABLE_OPTIONS,NO_FIELD_OPTIONS,NO_AUTO_CREATE_USER
Create Procedure: CREATE DEFINER="msandbox"@"localhost" PROCEDURE "maxdb_stored_routine"()
BEGIN
SELECT * FROM test;
END
character_set_client: utf8
collation_connection: utf8_general_ci
Database Collation: latin1_swedish_ci
1 row in set (0.00 sec)
```
若要解決此問題，請在用戶端上設定正確的 `sql_mode` 之後重新建立程序。
根據 [MySQL 文件](https://dev.mysql.com/doc/refman/5.7/en/create-procedure.html)，MySQL 會存放建立或修改常式時生效的 `sql_mode` 設定。無論常式啟動時的 `sql_mode` 設定為何，它一律會使用此設定執行常式。
在變更 `sql_mode` 之前，請參閱 MySQL 文件中的[伺服器 SQL 模式](https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html)。仔細評估對應用程式執行此操作的任何潛在影響。
在沒有不支援的 `sql_mode` 的情況下重新建立程序。
```
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)
```
預先檢查會成功。
```
{
"id": "maxdbFlagCheck",
"title": "Usage of obsolete MAXDB sql_mode flag",
"status": "OK",
"detectedProblems": []
}
```
**mysqlDollarSignNameCheck**
**預先檢查層級：警告**
**檢查物件名稱中是否已棄用單一美元符號**
從 [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) 開始，使用美元符號 (`$`) 作為未引用識別符的第一個字元已棄用。如果您有包含 `$` 作為第一個字元的任何結構描述、資料表、檢視、資料欄或常式，此預先檢查會傳回警告。雖然此警告不會阻止升級繼續進行，但我們建議您盡快採取動作來解決此問題。從 [MySQL 8.4](https://dev.mysql.com/doc/refman/8.4/en/mysql-nutshell.html)，任何此類識別符都會傳回語法錯誤，而不是警告。
**輸出範例：**
```
{
"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."
}
]
},
```
預先檢查會報告警告，因為 `test` 結構描述中的 `$deprecated_syntx` 資料表包含 `$` 作為第一個字元。
**reservedKeywordsCheck**
**預先檢查層級：警告**
**使用名稱與新預留關鍵字衝突的資料庫物件**
此檢查類似於 [routineSyntaxCheck](#routineSyntaxCheck)，因為它會檢查名稱與新預留關鍵字衝突的資料庫物件使用情況。雖然它們不會封鎖升級，但您需要仔細評估警告。
**輸出範例：**
使用上一個範例搭配名為 `except` 的資料表，預先檢查會傳回警告：
```
{
"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"
}
]
}
```
此警告可讓您知道可能有一些應用程式查詢需要檢閱。如果您的應用程式查詢未正確[逸出字串常值](https://dev.mysql.com/doc/refman/8.0/en/string-literals.html)，則升級到 MySQL 8.0 後可能會發生錯誤。檢閱您的應用程式，以確認、測試第 3 版上執行之 Aurora MySQL 資料庫叢集的複製或快照。
升級後將失敗的非逸出應用程式查詢範例：
```
SELECT * FROM escape;
```
升級後將成功的正確逸出應用程式查詢範例：
```
SELECT * FROM 'escape';
```
**utf8mb3Check**
**預先檢查層級：警告**
**`utf8mb3` 字元集的使用**
在 MySQL 8.0 中，`utf8mb3` 字元集已棄用，並將在未來 MySQL 主要版本中移除。如果偵測到使用此字元集的任何資料庫物件，則會實作此預先檢查以引發警告。雖然這不會阻止升級繼續進行，但強烈建議您考慮將資料表遷移到 `utf8mb4` 字元集，這是 MySQL 8.0 的預設值。如需 [utf8mb3](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb3.html) 和 [utf8mb4](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-utf8mb4.html) 的詳細資訊，請參閱 MySQL 文件中的[在 3 位元組和 4 位元組 Unicode 字元集之間轉換](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html)。
**輸出範例：**
```
{
"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"
}
]
}
```
若要解決此問題，請重建參考的物件和資料表。如需詳細資訊和先決條件，請參閱 MySQL 文件中的[在 3 位元組和 4 位元組 Unicode 字元集之間轉換](https://dev.mysql.com/doc/refman/8.0/en/charset-unicode-conversion.html)。
**zeroDatesCheck**
**預先檢查層級：警告**
**零日期、日期時間和時間戳記值**
MySQL 現在會對日期、日期時間和時間戳記資料欄使用零值強制執行更嚴格的規則。我們建議您使用 `NO_ZERO_IN_DATE` 和 `NO_ZERO_DATE SQL` 模式搭配 `strict` 模式，因為它們將在未來 MySQL 版本中與 `strict` 模式合併。
如果執行預先檢查時任何資料庫連線的 `sql_mode` 設定不包含這些模式，則預先檢查中會引發警告。使用者仍然可以插入包含零值的日期、日期時間和時間戳記值。不過，我們強烈建議將任何零值取代為有效值，因為其行為可能會在未來變更，而且可能無法正常運作。由於這是警告，因此不會封鎖升級，但建議您開始規劃以採取行動。
**輸出範例：**
```
{
"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 預先檢查
下列預先檢查專屬於 Aurora MySQL：
+ [auroraUpgradeCheckForRollbackSegmentHistoryLength](#auroraUpgradeCheckForRollbackSegmentHistoryLength)
+ [auroraUpgradeCheckForUncommittedRowModifications](#auroraUpgradeCheckForUncommittedRowModifications)
**auroraUpgradeCheckForRollbackSegmentHistoryLength**
**預先檢查層級：警告**
**檢查叢集的復原區段歷史記錄清單長度是否很高**
如 [auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions) 中所述，在執行主要版本升級程序時，Aurora MySQL 第 2 版資料庫執行個體必須經過[正常關閉](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown)。這可確保所有交易都已遞交或復原，而且 InnoDB 已清除所有復原日誌記錄。
如果您的資料庫叢集具有高復原區段歷史記錄清單長度 (HLL)，可能會延長 InnoDB 完成復原日誌記錄清除所需的時間，導致主要版本升級程序期間延長停機時間。如果預先檢查偵測到資料庫叢集上的 HLL 很高，就會引發警告。雖然這不會阻止您的升級繼續進行，但我們建議您密切監控資料庫叢集上的 HLL。將其保持在低水準可減少主要版本升級期間所需的停機時間。如需監控 HLL 的詳細資訊，請參閱 [InnoDB 歷史記錄清單長度顯著增加](proactive-insights.history-list.md)。
**輸出範例：**
```
{
"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."
}
]
}
```
預先檢查會傳回警告，因為它偵測到資料庫叢集 (82989114) 上的 InnoDB 復原 HLL 很高。雖然升級繼續進行，但根據要清除的復原數量，它可能會延長升級程序所需的停機時間。
我們建議您在生產環境中執行升級之前，先[調查資料庫叢集上的開啟中交易](proactive-insights.history-list.md)，以確保您的 HLL 保持在可管理的大小。
**auroraUpgradeCheckForUncommittedRowModifications**
**預先檢查層級：警告**
**檢查是否有許多未遞交的資料列修改**
如 [auroraUpgradeCheckForIncompleteXATransactions](#auroraUpgradeCheckForIncompleteXATransactions) 中所述，在執行主要版本升級程序時，Aurora MySQL 第 2 版資料庫執行個體必須經過[正常關閉](https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_slow_shutdown)。這可確保所有交易都已遞交或復原，而且 InnoDB 已清除所有復原日誌記錄。
如果您的資料庫叢集有已修改大量資料列的交易，則可能會延長 InnoDB 在清除關機程序中完成此交易復原所需的時間。如果預先檢查找到長時間執行的交易，且資料庫叢集上有大量修改的資料列，則會引發警告。雖然這不會阻止您的升級繼續進行，但我們建議您密切監控資料庫叢集上作用中交易的大小。將其保持在低水準可減少主要版本升級期間所需的停機時間。
**輸出範例：**
```
{
"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."
}
]
},
```
預先檢查會報告資料庫叢集包含具有 11,000,000 個未遞交資料列變更的交易，這些變更需要在正常關閉程序期間復原。升級會繼續進行，但為了減少升級程序期間的停機時間，建議您在生產叢集上執行升級之前監控並調查此問題。
若要檢視寫入器資料庫執行個體上的作用中交易，您可以使用 [information\$1schema.innodb\$1trx](https://dev.mysql.com/doc/refman/5.7/en/information-schema-innodb-trx-table.html) 資料表。下列寫入器資料庫執行個體的查詢會顯示資料庫叢集目前的交易、執行時間、狀態和修改的資料列。
```
# 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)
```
在遞交或復原交易之後，預先檢查不會再傳回警告。在復原任何大型交易之前，請參閱 MySQL 文件和您的應用程式團隊，因為復原可能需要一些時間才能完成，具體取決於交易大小。
```
{
"id": "auroraUpgradeCheckForUncommittedRowModifications",
"title": "Checks if there are many uncommitted modifications to rows",
"status": "OK",
"detectedProblems": []
},
```
如需有關最佳化 InnoDB 交易管理，以及在 MySQL 資料庫執行個體上執行和復原大型交易的潛在影響的詳細資訊，請參閱 MySQL 文件中的[最佳化 InnoDB 交易管理](https://dev.mysql.com/doc/refman/5.7/en/optimizing-innodb-transaction-management.html)。
## 注意
下列預先檢查會在預先檢查失敗時產生通知，但升級可以繼續。
**sqlModeFlagCheck**
**預先檢查層級：注意**
**使用過時的 `sql_mode` 旗標**
除了 `MAXDB` 之外，還[移除](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html)了許多其他 `sql_mode` 選項：`DB2`、`MSSQL`、`MYSQL323`、`MYSQL40``ORACLE`、`POSTGRESQL`、`NO_FIELD_OPTIONS`、`NO_KEY_OPTIONS` 和 `NO_TABLE_OPTIONS`。從 MySQL 8.0 開始，這些值都無法指派給 `sql_mode` 系統變數。如果此預先檢查使用這些 `sql_mode` 設定尋找任何開啟中工作階段，請確定已更新您的資料庫執行個體和資料庫叢集參數群組，以及用戶端應用程式和組態以停用它們。- 如需詳細資訊，請參閱 [MySQL 文件](https://dev.mysql.com/doc/refman/8.0/en/mysql-nutshell.html)。
**輸出範例：**
```
{
"id": "sqlModeFlagCheck",
"title": "Usage of obsolete sql_mode flags",
"status": "OK",
"detectedProblems": []
}
```
若要解決任何這些預先檢查失敗，請參閱 [maxdbFlagCheck](#maxdbFlagCheck)。
## 錯誤、警告或通知
視預先檢查輸出而定，下列預先檢查可能會傳回錯誤、警告或通知。
**checkTableOutput**
**預先檢查層級：錯誤、警告或通知**
**`check table x for upgrade` 命令報告的問題**
開始升級至 Aurora MySQL 第 3 版之前，`check table for upgrade` 會在資料庫叢集的使用者結構描述中的每個資料表上執行。此預先檢查與 [checkTableMysqlSchema](#checkTableMysqlSchema) 不同。
`check table for upgrade` 命令會檢查資料表是否有任何在升級至較新版本的 MySQL 期間可能發生的潛在問題。在嘗試升級之前執行此命令有助於事先識別和解決任何不相容，使實際的升級程序更順暢。
此命令會對每個資料表執行各種檢查，如下所示：
+ 確認資料表結構和中繼資料是否與目標 MySQL 版本相容
+ 檢查資料表使用的任何已棄用或已移除的功能
+ 確保資料表可以正確升級，而不會遺失資料
與其他預先檢查不同，它可能會根據 `check table` 輸出傳回錯誤、警告或通知。如果此預先檢查傳回任何資料表，請在起始升級之前仔細檢閱它們，以及傳回程式碼和訊息。如需詳細資訊，請參閱 MySQL 文件中的 [CHECK TABLE 陳述式](https://dev.mysql.com/doc/refman/5.7/en/check-table.html)。
我們在這裡提供錯誤範例和警告範例。
**錯誤範例：**
```
{
"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"
}
]
},
```
預先檢查會報告 `test.parent` 資料表不存在的錯誤。
寫入器資料庫執行個體的 `mysql-error.log` 檔案顯示有外部索引鍵錯誤。
```
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.
```
登入寫入器資料庫執行個體並執行 `show engine innodb status\G` 以取得外部索引鍵錯誤的詳細資訊。
```
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.
.
.
```
`LATEST FOREIGN KEY ERROR` 訊息報告 `test.child` 資料表中參考 `test.parent` 資料表的 `fk_pname` 外部索引鍵限制條件缺少索引或資料類型不相符。有關[外部索引鍵限制條件](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html)的 MySQL 文件指出外部索引鍵中參考的資料欄必須具有相關聯的索引，且父/子資料欄必須使用相同的資料類型。
若要確認這是否與缺少索引或資料類型不符有關，請登入資料庫，並暫時停用工作階段變數 [foreign\$1key\$1checks](https://dev.mysql.com/doc/refman/5.7/en/create-table-foreign-keys.html#foreign-key-checks) 來檢查資料表定義。這麼做之後，我們可以看到有問題的子限制條件 (`fk_pname`) 使用 `p_name varchar(20) CHARACTER SET latin1 DEFAULT NULL` 來參考父資料表 `name varchar(20) NOT NULL`。父資料表使用 `DEFAULT CHARSET=utf8`，但子資料表的 `p_name` 資料欄使用 `latin1`，因此擲回資料類型不相符錯誤。
```
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)
```
若要解決此問題，我們可以將子資料表變更為使用與父系相同的字元集，或將父資料表變更為使用與子資料表相同的字元集。在這裡，由於子資料表在 `p_name` 資料欄定義中明確使用 `latin1`，因此我們執行 `ALTER TABLE` 將字元集修改為 `utf8`。
```
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)
```
執行此操作後，預先檢查會通過，而且升級可以繼續。
**警告範例：**
```
{
"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."
}
]
}
```
預先檢查會報告 `test.orders` 資料表上 `delete_audit_trigg` 觸發條件的警告，因為它沒有 `CREATED` 屬性。根據 MySQL 文件中的[檢查版本相容性](https://dev.mysql.com/doc/refman/5.7/en/check-table.html#check-table-version-compatibility)，此訊息是資訊性的，並針對在 MySQL 5.7.2 之前建立的觸發條件進行列印。
由於這是警告，因此不會封鎖升級繼續進行。不過，如果您想要解決問題，您可以重新建立有問題的觸發條件，而預先檢查會成功且沒有警告。
```
{
"id": "checkTableOutput",
"title": "Issues reported by 'check table x for upgrade' command",
"status": "OK",
"detectedProblems": []
},
```
# 就地升級執行方式
建議您檢閱[Aurora MySQL 主要版本就地升級的運作方式](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence)中的背景資料。
執行任何升級前規劃和測試，如 [規劃 Aurora MySQL 叢集的主要版本升級](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Planning) 中所述。
## 主控台
下列範例會將 `mydbcluster-cluster` 資料庫叢集升級至 Aurora MySQL 3.04.1 版。
**升級 Aurora MySQL 資料庫叢集的主要版本**
1. 登入 AWS 管理主控台，開啟位於 [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/) 的 Amazon RDS 主控台。
1. 如果您已對原始資料庫叢集使用自訂參數群組，請建立與新主要版本相容的對應參數群組。對該新參數群組中的組態參數進行任何必要的調整。如需更多詳細資訊，請參閱 [就地升級如何影響叢集的參數群組](#AuroraMySQL.Upgrading.ParamGroups)。
1. 在導覽窗格中，選擇 **Databases** (資料庫)。
1. 在清單中，選擇您要修改的資料庫叢集。
1. 選擇 **Modify (修改)**。
1. 對於 **Version** (版本)，請選擇新的 Aurora MySQL 主要版本。
我們通常建議使用主要版本的最新次要版本。在這裡，我們選擇目前的預設版本。
![\[將 Aurora MySQL 資料庫叢集從第 2 版就地升級至第 3 版\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/ams-upgrade-v2-v3.png)
1. 選擇 **Continue (繼續)**。
1. 在下一頁中，指定執行升級的時間。選擇 **During the next scheduled maintenance window** (在下一個排程的維護期間) 或 **Immediately** (立即)。
1. (選用) 在升級期間，定期檢查 RDS 主控台中的 **Events** (事件) 頁面。這樣做可協助您監控升級的進度，並找出任何問題。如果升級發生任何問題，請參閱 [Aurora MySQL 就地升級疑難排解](AuroraMySQL.Upgrading.Troubleshooting.md) 以了解要採取的步驟。
1. 如果您在此程序開始時建立了新的參數群組，請將自訂參數群組與升級的叢集建立關聯。如需更多詳細資訊，請參閱 [就地升級如何影響叢集的參數群組](#AuroraMySQL.Upgrading.ParamGroups)。
**注意**
執行此步驟需要再次啟動叢集，才能套用新的參數群組。
1. (選用) 完成任何升級後測試後，請刪除升級開始時 Aurora 建立的手動快照。
## AWS CLI
若要升級 Aurora MySQL 資料庫叢集的主要版本，請使用具有下列必要參數的 AWS CLI [modify-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-db-cluster.html) 命令：
+ `--db-cluster-identifier`
+ `--engine-version`
+ `--allow-major-version-upgrade`
+ `--apply-immediately` 或 `--no-apply-immediately` \$1
如果您的叢集使用任何自訂參數群組，也請包含下列其中一個或兩個選項：
+ `--db-cluster-parameter-group-name` (如果叢集使用自訂叢集參數群組)
+ `--db-instance-parameter-group-name` (如果叢集中的任何執行個體使用自訂資料庫參數群組)
下列範例會將 `sample-cluster` 資料庫叢集升級至 Aurora MySQL 3.04.1 版。升級會立即進行，而不是等待下一個維護時段。
**Example**
對於 Linux、macOS 或 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
```
在 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
```
您可以將其他 CLI 命令與 `modify-db-cluster` 合併，建立自動化端對端程序，以執行和驗證升級。如需詳細資訊和範例，請參閱 [Aurora MySQL 會就地升級教學](AuroraMySQL.Upgrading.Tutorial.md)。
**注意**
如果您的叢集是 Aurora 全域資料庫的一部分，就地升級程序會略有差異。呼叫 [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) 命令操作，而不是 `modify-db-cluster`。如需更多詳細資訊，請參閱 [全域資料庫的就地主要升級](#AuroraMySQL.Upgrading.GlobalDB)。
## RDS API
若要升級 Aurora MySQL 資料庫叢集的主要版本，請搭配下列必要參數使用 RDS API 操作 [ModifyDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyDBCluster.html)：
+ `DBClusterIdentifier`
+ `Engine`
+ `EngineVersion`
+ `AllowMajorVersionUpgrade`
+ `ApplyImmediately` (設定為 `true` 或 `false`)
**注意**
如果您的叢集是 Aurora 全域資料庫的一部分，就地升級程序會略有差異。呼叫 [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalClusterParameterGroup.html) 操作，而不是 `ModifyDBCluster`。如需更多詳細資訊，請參閱 [全域資料庫的就地主要升級](#AuroraMySQL.Upgrading.GlobalDB)。
## 就地升級如何影響叢集的參數群組
對於與 MySQL 5.7 或 8.0 相容的叢集，Aurora 參數群組具有不同的組態設定集。當您執行就地升級時，升級的叢集及其所有執行個體必須使用對應的叢集和執行個體參數群組。
您的叢集和執行個體可能會使用預設的 5.7 相容參數群組。若是如此，升級的叢集和執行個體會以預設的 8.0 相容參數群組開始。如果您的叢集和執行個體使用任何自訂參數群組，請務必建立對應的 8.0 相容參數群組。此外，亦請務必在升級過程中指定這些項目。
**注意**
對於大部分參數設定，您可以在兩點選擇自訂參數群組。這些是您建立叢集或在將參數群組與叢集建立關聯時。
不過，如果您對 `lower_case_table_names` 參數使用非預設設定，則必須預先使用此設定來設定自訂參數群組。然後，在執行快照還原來建立叢集時指定參數群組。在建立叢集之後，對 `lower_case_table_names` 參數的任何變更都無效。
當您從 Aurora MySQL 第 2 版升級到第 3 版時，我們建議您針對 `lower_case_table_names` 使用相同的設定。
使用以 Aurora MySQL 為基礎的 Aurora 全球資料庫時，只有將 `lower_case_table_names` 參數設為預設值並重新啟動全球資料庫，才能從 Aurora MySQL 第 2 版就地升級至第 3 版。如需詳細了解您可以使用的方法，請參閱 [主要版本升級](aurora-global-database-upgrade.md#aurora-global-database-upgrade.major)。
## 在 Aurora MySQL 版本之間對叢集屬性的變更
當您從 Aurora MySQL 第 2 版升級至第 3 版時，請務必確認用於設定或管理 Aurora MySQL 叢集和資料庫執行個體的任何應用程式或指令碼。
此外，變更操作參數群組的程式碼，以考慮預設參數群組名稱對於 5.7 和 8.0 相容叢集不同的事實。Aurora MySQL 第 2 版和第 3 版叢集的預設參數群組名稱分別為 `default.aurora-mysql5.7` 和 `default.aurora-mysql8.0`。
例如，在升級之前，可能會有如下所示的程式碼套用至叢集。
```
# 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
```
升級叢集的主要版本後，如下所示修改該程式碼。
```
# 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
```
## 全域資料庫的就地主要升級
若為 Aurora 全域資料庫，您可以升級全域資料庫叢集。Aurora 會自動同時升級所有叢集，並確保其皆執行相同的引擎版本。這項要求是因為對系統資料表、資料檔案格式等所做的任何變更都會自動複寫至所有次要叢集。
請遵循中的說明進行[Aurora MySQL 主要版本就地升級的運作方式](AuroraMySQL.Updates.MajorVersionUpgrade.md#AuroraMySQL.Upgrading.Sequence) 在您指定要升級的內容時，請確認已選擇全域資料庫叢集，而非其中包含的其中一個叢集。
若您使用 AWS 管理主控台，請選擇具有 **Global database** (全域資料庫) 角色的項目。
![\[升級全域資料庫叢集\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/images/aurora-global-databases-major-upgrade-global-cluster.png)
如果您使用 AWS CLI 或 RDS API，請呼叫 [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) 命令或 [ModifyGlobalCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_ModifyGlobalCluster.html) 操作來啟動升級程序。您會使用其中一個，而不是 `modify-db-cluster` 或 `ModifyDBCluster`。
**注意**
在執行 Aurora 全球資料庫的主要版本升級時，無法為全域資料庫叢集指定自訂參數群組。在全域叢集的每個區域中建立您的自訂參數群組。然後，在升級後手動將其套用至區域叢集。
若要透過使用 AWS CLI 來升級 Aurora MySQL 全球資料庫叢集的主要版本，請使用具有下列必要參數的 [modify-global-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/modify-global-cluster.html) 命令：
+ `--global-cluster-identifier`
+ `--engine aurora-mysql`
+ `--engine-version`
+ `--allow-major-version-upgrade`
下列範例會將全球資料庫叢集升級至 Aurora MySQL 3.04.2 版。
**Example**
對於 Linux、macOS 或 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
```
在 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
```
## 使用跨區域僅供讀取複本進行資料庫叢集就地升級
您可以使用就地升級程序升級具有跨區域僅供讀取複本的 Aurora 資料庫叢集，但有一些考量：
+ 您必須先升級僅供讀取複本資料庫叢集。如果您嘗試先升級主要叢集，您會收到錯誤訊息，如下所示：
無法升級資料庫叢集 test-xr-primary-cluster，因為關聯的 Aurora 跨區域複本 test-xr-replica-cluster 尚未修補。請升級 Aurora 跨區域複本，然後再試一次。
這表示主要資料庫叢集的資料庫引擎版本不能高於複本叢集。
+ 升級主要資料庫叢集之前，請先停止寫入工作負載，並停用對主要叢集寫入器資料庫執行個體的任何新連線請求。
+ 當您升級主要叢集時，請選擇自訂資料庫叢集參數群組，並將 `binlog_format` 參數設定為支援二進位記錄複寫的值，例如 `MIXED`。
如需搭配 Aurora MySQL 使用二進位記錄的詳細資訊，請參閱 [Aurora 與 MySQL 之間或 Aurora 與另一個 Aurora 資料庫叢集之間的複寫 (二進位複寫)](AuroraMySQL.Replication.MySQL.md)。如需修改 Aurora MySQL 組態參數的詳細資訊，請參閱 [Aurora MySQL 組態參數](AuroraMySQL.Reference.ParameterGroups.md) 和 [Amazon Aurora 的參數群組](USER_WorkingWithParamGroups.md)。
+ 升級複本叢集之後，請勿等待很長的時間才升級主要資料庫叢集。我們建議不要等待超過下一個維護時段。
+ 升級主要資料庫叢集之後，請重新啟動其寫入器資料庫執行個體。在寫入器資料庫執行個體重新啟動之前，啟用 binlog 複寫的自訂資料庫叢集參數群組不會生效。
+ 在您確認跨區域複寫已重新啟動，且次要 AWS 區域 中的複本延遲為 0 之前，請勿繼續寫入工作負載或啟用寫入器資料庫執行個體的連線。
# Aurora MySQL 會就地升級教學
下列 Linux 範例顯示如何使用 AWS CLI 來執行就地升級程序的一般步驟。
這第一個範例會建立執行 2.x 版 Aurora MySQL 的 Aurora 資料庫叢集。叢集包含寫入器資料庫執行個體和讀取器資料庫執行個體。`wait db-instance-available` 命令會暫停，直至寫入器資料庫執行個體可供使用為止。這正是叢集準備好升級之時。
```
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
```
您可以升級叢集的 Aurora MySQL 3.x 版本取決於叢集目前執行的 2.x 版本，以及叢集所在的 AWS 區域。使用第一個命令 `--output text`，只是顯示可用的目標版本。第二個命令顯示回應的完整 JSON 輸出。在該回應中，您可以查看詳細資訊，例如用於 `engine` 參數的 `aurora-mysql` 值。您還可以查看升級至 3.04.0 代表主要版本升級的事實。
```
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
},
...
```
此範例說明，如果您輸入的目標版本編號不是叢集的有效升級目標，Aurora 不會執行升級。Aurora 也不會執行主要版本升級，除非您包含 `--allow-major-version-upgrade` 參數。如此一來，您就不會意外執行可能需要對應用程式的程式碼進行大量測試和變更的升級。
```
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"
}
```
叢集和相關資料庫執行個體的狀態需要一段時間才能變更為 `upgrading`。叢集和資料庫執行個體的版本編號只有在升級完成時才會變更。同樣，您可以使用寫入器資料庫執行個體的 `wait db-instance-available` 命令，等到升級完成後再繼續進行。
```
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
```
此時，叢集的版本編號符合針對升級指定的版本編號。
```
aws rds describe-db-clusters --db-cluster-identifier mynewdbcluster \
--query '*[].[EngineVersion]' --output text
8.0.mysql_aurora.3.04.0
```
上述範例透過指定 `--apply-immediately` 參數立即執行升級。若要讓升級在方便的時間，當叢集不忙碌時發生，您可以指定 `--no-apply-immediately` 參數。這樣做會在叢集的下一個維護時段期間啟動升級。維護時段會定義維護操作可以開始的期間。長時間執行的操作可能無法在維護時段完成。因此，即使您預期升級可能需要很長時間，也不需要定義較大的維護時段。
下列範例會升級最初執行 Aurora MySQL 2.11.2 版的叢集。在 `describe-db-engine-versions` 輸出中，`False` 和 `True` 值表示 `IsMajorVersionUpgrade` 屬性。從 2.11.2 版開始，您可以升級至其他 2.\$1 版本。這些升級不會視為主要版本升級，因此不需要就地升級。就地升級僅適用於升級至清單中顯示的 3.\$1 版。
```
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
...
```
在沒有指定維護時段的情況下建立叢集時，Aurora 會隨機挑選一週中的一天。在這種情況下，`modify-db-cluster` 命令會在週一提交。因此，我們將維護時段變更為週二上午。所有時間都以 UTC 時區表示。`tue:10:00-tue:10:30` 時段對應於太平洋時間上午 2:00-2:30。維護時段中的變更會立即生效。
```
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"
]
]
```
下列範例顯示如何取得升級產生事件的報告。`--duration` 引數代表擷取事件資訊的分鐘數。此引數是必要的，因為根據預設，`describe-events` 僅傳回最後一小時的事件。
```
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"
}
]
}
```
# 尋找 Aurora MySQL 主要版本升級失敗的原因
在[教學課程](AuroraMySQL.Upgrading.Tutorial.md)中，從 Aurora MySQL 第 2 版升級至第 3 版成功。但是，如果升級失敗，您會想知道原因。
您可以從使用 `describe-events` AWS CLI 命令開始查看資料庫叢集事件。此範例顯示過去 10 小時內 `mydbcluster` 的事件。
```
aws rds describe-events \
--source-type db-cluster \
--source-identifier mydbcluster \
--duration 600
```
在這種情況下，我們發生升級預先檢查失敗。
```
{
"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"
}
]
}
```
若要診斷問題的確切原因，請檢查寫入器資料庫執行個體的資料庫日誌。升級到 Aurora MySQL 第 3 版失敗時，寫入器執行個體會包含一個日誌檔案，名稱為 `upgrade-prechecks.log`。此範例說明如何偵測該日誌是否存在，然後將其下載為本機檔案進行檢查。
```
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
```
`upgrade-prechecks.log` 檔案為 JSON 格式。我們使用 `--output text` 選項來下載檔案，避免在另一個 JSON 包裝函式中對 JSON 輸出進行編碼。針對 Aurora MySQL 第 3 版升級，此日誌一律包含特定資訊和警告訊息。它只會在升級失敗時包含錯誤訊息。如果升級成功，則根本不會產生日誌檔案。
若要摘要所有錯誤並顯示關聯的物件和描述欄位，您可以對 `upgrade-prechecks.log` 檔案的內容執行命令 `grep -A 2 '"level": "Error"'`。這麼做會顯示每個錯誤行及其後兩行。其中包含對應資料庫物件的名稱，以及如何修正問題的指引。
```
$ 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."
```
在此範例中，您可以在違規的資料表上執行下列 SQL 命令，嘗試修正問題，也可以在沒有懸置索引的情況下重新建立資料表。
```
OPTIMIZE TABLE problematic_upgrade.dangling_fulltext_index;
```
然後重試升級。
# Aurora MySQL 就地升級疑難排解
使用下列提示有助於對 Aurora MySQL 就地升級的問題進行疑難排解。這些提示不適用於 Aurora Serverless 資料庫叢集。
| 就地升級被取消或緩慢的原因 | Effect | 允許在維護時段完成就地升級的解決方案 |
| --- | --- | --- |
| 相關聯的 Aurora 跨區域複本尚未修補 | Aurora 會取消升級。 | 請升級 Aurora 跨區域複本，然後再試一次。 |
| 叢集的 XA 交易處於準備狀態 | Aurora 會取消升級。 | 遞交或復原所有準備好的 XA 交易。 |
| 叢集正在處理任何資料定義語言 (DDL) 陳述式 | Aurora 會取消升級。 | 在所有 DDL 陳述式完成後，請等待並執行升級。 |
| 叢集中的多行有未遞交的變更 | 升級可能需要很長時間。 | 升級程序會復原未遞交的變更。此條件的指標為 `TRX_ROWS_MODIFIED` 資料表 `INFORMATION_SCHEMA.INNODB_TRX` 中的值。 僅在遞交或復原所有大型交易之後，才考慮執行升級。 |
| 叢集具有大量的復原記錄 | 升級可能需要很長時間。 | 即使未遞交的交易不會影響大量的資料列，也可能會涉及大量資料。例如，您可能插入大型 BLOB。Aurora 不會自動偵測或產生這種交易活動的事件。此情況的指標為歷史記錄清單長度 (HLL)。升級程序會復原未遞交的變更。 您可以從 `SHOW ENGINE INNODB STATUS` SQL 命令檢查輸出中的 HLL，或直接使用以下 SQL 查詢： SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
您也可以在 Amazon CloudWatch 中監控 `RollbackSegmentHistoryListLength` 指標。 僅在 HLL 減小之後，才考慮執行升級。 |
| 叢集正在遞交大型二進位日誌交易 | 升級可能需要很長時間。 | 升級程序會等到套用二進位日誌變更之後。在此期間，可能會啟動更多交易或 DDL 陳述式，進一步降低升級程序的速度。 在叢集不忙於產生二進位日誌複寫變更時排程升級程序。Aurora 不會自動偵測或產生此條件的事件。 |
| 因檔案移除或損毀所導致的結構描述不一致 | Aurora 會取消升級。 | 將暫存資料表的預設儲存引擎從 MyISAM 變更為 InnoDB。執行以下步驟： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Upgrading.Troubleshooting.html) |
| 主要使用者已刪除 | Aurora 會取消升級。 | 請勿刪除主要使用者。 不過，如果由於某些原因，您應該刪除主要使用者，並使用下列 SQL 命令進行還原： 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;
|
如需故障診斷導致升級預先檢查失敗之問題的詳細資訊，請參閱下列部落格：
+ [Amazon Aurora MySQL 第 2 版 (與 MySQL 5.7 相容) 到第 3 版 (與 MySQL 8.0 相容) 升級檢查清單，第 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/)
+ [Amazon Aurora MySQL 第 2 版 (與 MySQL 5.7 相容) 到第 3 版 (與 MySQL 8.0 相容) 升級檢查清單，第 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/)
您可以使用下列步驟，對以上資料表中的某些條件執行自己的檢查。如此一來，在您知道資料庫處於升級可以順利且快速完成的狀態時，即可排程升級。
+ 您可以執行 `XA RECOVER` 陳述式，來檢查開啟的 XA 交易。您隨後可以遞交或復原 XA 交易，再開始升級。
+ 您可以執行 `SHOW PROCESSLIST` 陳述式，然後在輸出中尋找 `CREATE`、`DROP`、`ALTER`、`RENAME` 和 `TRUNCATE`，來檢查 DDL 陳述式。在開始升級之前，允許所有 DDL 陳述式完成。
+ 您可以查詢 `INFORMATION_SCHEMA.INNODB_TRX` 資料表，檢查未遞交列的總數。該資料表包含每項交易的一個資料列。`TRX_ROWS_MODIFIED` 資料欄包含交易修改或插入的列數。
+ 您可以執行 `SHOW ENGINE INNODB STATUS SQL` 陳述式，然後在輸出中尋找 `History list length`，來檢查 InnoDB 歷史記錄清單的長度。您還可以直接執行下列查詢來檢查值：
```
SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';
```
歷史記錄清單的長度對應於資料庫存放的還原資訊量，以實作多版本並行控制 (MVCC)。
# Aurora MySQL 第 3 版的升級後清除
完成將任何 Aurora MySQL 第 2 版叢集升級至 Aurora MySQL 第 3 版之後，您可以執行下列其他清除動作：
+ 為任何自訂參數群組建立新的 MySQL 8.0 相容版本。將任何必要的自訂參數值套用至新的參數群組。
+ 更新任何 CloudWatch 警示、設定指令碼等，以針對其名稱受到包容性語言變更影響的任何指標使用新名稱。如需這類指標的清單，請參閱 [Aurora MySQL 第 3 版的包容性語言變更](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language)。
+ 更新任何 CloudFormation 範本，針對其名稱受到包容性語言變更影響的任何組態參數使用新名稱。如需這類參數的清單，請參閱 [Aurora MySQL 第 3 版的包容性語言變更](AuroraMySQL.Compare-v2-v3.md#AuroraMySQL.8.0-inclusive-language)。
## 空間索引
升級至 Aurora MySQL 第 3 版之後，請檢查您是否需要捨棄或重新建立與空間索引相關的物件和索引。在 MySQL 8.0 之前，Aurora 可以使用不包含空間資源識別符 (SRID) 的索引來最佳化空間查詢。Aurora MySQL 第 3 版只使用包含 SRID 的空間索引。在升級期間，Aurora 會自動捨棄任何沒有 SRID 的空間索引，並在資料庫日誌中列印警告訊息。如果您觀察到這類警告訊息，請在升級之後使用 SRID 建立新的空間索引。如需 MySQL 8.0 中對空間函數和資料類型之變更的詳細資訊，請參閱《MySQL 參考手冊》**中的 [MySQL 8.0 中的變更](https://dev.mysql.com/doc/refman/8.0/en/upgrading-from-previous-series.html)。