Aurora MySQL 就地升級疑難排解 - Amazon Aurora

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

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。執行以下步驟：

  1. 將 default_tmp_storage_engine 資料庫參數修改為 InnoDB。

  2. 重新啟動資料庫叢集。

  3. 重新啟動後，請確認 default_tmp_storage_engine 資料庫參數已設定為 InnoDB。使用下列命令：

    show global variables like 'default_tmp_storage_engine';

  4. 切勿建立任何使用 MyISAM 儲存引擎的暫存資料表。我們建議您暫停任何資料庫工作負載，且勿建立任何新的資料庫連線，因為即將進行升級。

  5. 請再次嘗試就地升級。
主要使用者已刪除 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;

如需故障診斷導致升級預先檢查失敗之問題的詳細資訊，請參閱下列部落格：

您可以使用下列步驟，對以上資料表中的某些條件執行自己的檢查。如此一來，在您知道資料庫處於升級可以順利且快速完成的狀態時，即可排程升級。

  • 您可以執行 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)。