Aurora 疑難排解我的SQL就地升級 - Amazon Aurora

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

Aurora 疑難排解我的SQL就地升級

使用下列提示可協助疑難排解 Aurora My SQL 就地升級的問題。這些提示不適用於 Aurora Serverless 資料庫叢集。

就地升級被取消或緩慢的原因 Effect 允許在維護時段完成就地升級的解決方案
尚未修補關聯的 Aurora 跨區域複本 Aurora 會取消升級。 升級 Aurora 跨區域複本，然後再試一次。
叢集的 XA 交易處於準備狀態 Aurora 會取消升級。 遞交或復原所有準備好的 XA 交易。
群集正在處理任何數據定義語言（DDL）語句 Aurora 會取消升級。 在所有DDL陳述式完成之後，請考慮等待並執行升級。
叢集中的多行有未遞交的變更 升級可能需要很長時間。

升級程序會復原未遞交的變更。此條件的指標為 TRX_ROWS_MODIFIED 資料表 INFORMATION_SCHEMA.INNODB_TRX 中的值。

僅在遞交或復原所有大型交易之後，才考慮執行升級。
叢集具有大量的復原記錄 升級可能需要很長時間。

即使未遞交的交易不會影響大量的資料列，也可能會涉及大量資料。例如，您插入的可能很大BLOBs。Aurora 不會自動偵測或產生這種交易活動的事件。此條件的指標是歷史記錄列表長度（HLL）。升級程序會復原未遞交的變更。

您可以從SHOW ENGINE INNODB STATUSSQL命令HLL中檢查輸出，或直接使用以下SQL查詢：

SELECT count FROM information_schema.innodb_metrics WHERE name = 'trx_rseg_history_len';

您還可以在 Amazon 中監視RollbackSegmentHistoryListLength指標 CloudWatch。

請考慮只在較小之後HLL執行升級。
叢集正在遞交大型二進位日誌交易 升級可能需要很長時間。

升級程序會等到套用二進位日誌變更之後。在此期間可能會啟動更多交易或DDL陳述式，進一步降低升級程序的速度。

在叢集不忙於產生二進位日誌複寫變更時排程升級程序。Aurora 不會自動偵測或產生此條件的事件。
因檔案移除或損毀所導致的結構描述不一致 Aurora 會取消升級。

將臨時表的默認存儲引擎從我的更改ISAM為 InnoDB。執行以下步驟：

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

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

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

    show global variables like 'default_tmp_storage_engine';

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

  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 交易，再開始升級。

  • 您可以透過執行DDL陳述式並在輸出中尋找CREATE、、DROPALTERRENAME、和TRUNCATE陳述式來檢查陳述式。SHOW PROCESSLIST在開始升級之前，允許所有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。