本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# Aurora MySQL 就地升級疑難排解
<a name="AuroraMySQL.Upgrading.Troubleshooting"></a>

使用下列提示有助於對 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 查詢： <pre>SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';</pre> 您也可以在 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 命令進行還原： <pre>CREATE USER 'master_username'@'%' IDENTIFIED BY 'master_user_password' REQUIRE NONE PASSWORD EXPIRE DEFAULT ACCOUNT UNLOCK;<br /><br />GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, <br />LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, <br />TRIGGER, LOAD FROM S3, SELECT INTO S3, INVOKE LAMBDA, INVOKE SAGEMAKER, INVOKE COMPREHEND ON *.* TO 'master_username'@'%' WITH GRANT OPTION;</pre>  | 

如需故障診斷導致升級預先檢查失敗之問題的詳細資訊，請參閱下列部落格：
+ [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)。