我的 Aurora 的主要版本升級預先檢查 SQL - Amazon Aurora

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

我的 Aurora 的主要版本升級預先檢查 SQL

我的 SQL 8.0 包含一些與我的 5.7 不兼容的問題。SQL從 Aurora 我的版本 2 升級到SQL版本 3 時,這些不相容性可能會造成問題。您的資料庫可能需要一些準備才能成功升級。

當您從 Aurora 我的SQL版本 2 開始升級到版本 3 時,Amazon Aurora 會自動執行預先檢查以偵測這些不相容性。

系統會強制執行這些前置檢查,您無法選擇略過這些檢查。前置檢查提供以下優勢:

預先檢查包括一些包含在 My SQL 和一些由 Aurora 團隊專門創建的。如需 My 提供之預先檢查的相關資訊SQL,請參閱升級檢查程式公用程式

前置檢查會在系統將資料庫執行個體停止以進行升級前執行,意即前置檢查執行期間不會造成任何停機時間。如果預先檢查發現不相容,Aurora 會在資料庫執行個體停止之前自動取消升級。Aurora 也會產生不相容的事件。如需有關 Amazon Aurora 事件的詳細資訊,請參閱使用 Amazon RDS 事件通知

Aurora 會在記錄檔PrePatchCompatibility.log中記錄有關每個不相容性的詳細資訊。在大多數情況下,記錄項目會包含 My SQL 文件的連結,以修正不相容性。如需檢視日誌檔案的詳細資訊,請參閱檢視並列出資料庫日誌檔案

根據前置檢查的特性,這些檢查作業會分析資料庫中的物件。此分析會耗用資源,並增加升級完成的時間。

社群我的SQL升級預先檢查

以下是 My SQL 5.7 和 8.0 之間不相容性的一般清單:

  • 與 My SQL 5.7 相容的資料庫叢集不得使用 My 8.0 中不支援的功能。SQL

    如需詳細資訊,請參閱我的SQL文件中的 My SQL 8.0 中移除的功能

  • 不能違反關鍵字或保留字的規定。某些關鍵字可能會保留在 My SQL 8.0 中,這些關鍵字之前沒有保留。

    如需詳細資訊,請參閱 My SQL 文件中的關鍵字和保留字。

  • 運用 Unicode 增強支援時,請考慮將使用 utf8mb3 字元集的物件轉換成使用 utf8mb4 字元集,因為 utf8mb3 字元集已棄用。另外,utf8mb4 目前是 utf8 字元集的別名,因此請考慮使用 utf8 做為字元集參考,而不是 utf8mb3

    如需詳細資訊,請參閱我的文件中的 utf8mb3 字元集 (3 位元組 UTF -8 Unicode 編碼)。SQL

  • 不得有具有非默認行格式的 InnoDB 表。

  • 必須沒有ZEROFILLdisplay長度類型屬性。

  • 分割資料表所使用的儲存引擎皆需提供原生分割支援。

  • My SQL 5.7 mysql 系統資料庫中不得有與 My SQL 8.0 資料字典所使用之資料表名稱相同的表格。

  • 資料表不能使用過時的資料類型或函數。

  • 外部索引鍵的限制條件名稱不得超過 64 個字元。

  • 您的sql_mode系統變數設定中不得定義過時的SQL模式。

  • 不得有個別或SET欄元素長度超過 255 個字元的資料表ENUM或預存程序。

  • 不得有駐留在共享 InnoDB 表空間中的表分區。

  • 表格空間資料檔路徑中不得有循環參照。

  • 不得有使用GROUP BY條款ASCDESC限定元的查詢和預存程式定義。

  • 必須沒有移除的系統變數,且系統變數必須為 My SQL 8.0 使用新的預設值。

  • 不得有零 (0) 日期、日期時間或時間戳記值。

  • 檔案移除或損毀不得有結構描述不一致的情況。

  • 不得有包含字FTS元字串的資料表名稱。

  • 不得有屬於不同引擎的 InnoDB 表。

  • My SQL 5.7 中必須沒有無效的資料表或結構描述名稱。

如需有關升級至 My SQL 8.0 的詳細資訊,請參閱我的SQL文件SQL中的升級我的。

Aurora 我的SQL升級預檢

從版本 2 升級到版本 3 時,我的 Aurora SQL 有自己的特定要求:

  • 在檢視、常式、觸發程序和QUERY_CACHE事件中不得有不推薦使用的SQL語法,例如、和。SQL_CACHE SQL_NO_CACHE

  • 不得有沒有FTS索引的任何表上存在任何FTS_DOC_ID列。

  • InnoDB 資料字典和實際資料表定義之間不得有資料行定義不相符。

  • lower_case_table_names參數設定為時,所有資料庫和表格名稱都必須為小寫1

  • 事件和觸發程序不得有遺失或空白的定義器或無效的建立內容。

  • 資料庫中的所有觸發器名稱都必須是唯一的。

  • DDLAurora 我的SQL版本 3 DDL 不支持恢復和快速。與這些功能相關的資料庫中不得有人工因素。

  • 具有REDUNDANTCOMPACT資料列格式的資料表不能有大於 767 個位元組的索引。

  • tiny文本列上定義的索引的前綴長度不能超過 255 個字節。使用utf8mb4字元集時,這會將支援的首碼長度限制為 63 個字元。

    My SQL 5.7 中允許使用innodb_large_prefix 參數更大的前綴長度。此參數在我的 SQL 8.0 中已棄用。

  • mysql.host中不得有 InnoDB 元數據不一致。

  • 系統資料表中不得有資料行資料類型不相符。

  • prepared州不得有 XA 交易。

  • 檢視中的欄名稱不得超過 64 個字元。

  • 存儲過程中的特殊字符不能不一致。

  • 資料表不能有資料檔案路徑不一致。

Aurora 我的SQL主要版本升級路徑

並非所有類型或版本的 Aurora 我的SQL叢集都可以使用就地升級機制。您可以參閱下表,瞭解每個 Aurora My SQL 叢集的適當升級路徑。

Aurora 的類型我的SQL資料庫叢集 是否可以採用就地升級? 動作

Aurora 我SQL佈建的叢集,2.0 或更高版本

5.7 相容的 Aurora 我的SQL叢集支援就地升級。

如需有關升級至 Aurora 我的SQL版本 3 的資訊,請參閱規劃 Aurora 我的SQL叢集的主要版本升級就地升級執行方式

Aurora 我的SQL佈建叢集,3.01.0 或更高版本

N/A

使用次要版本升級程序在 Aurora 我的SQL版本 3 版本之間進行升級。

Aurora Serverless v1 叢集

N/A

目前,Aurora Serverless v1SQL僅在版本 2 上支援「我的 Aurora」。

Aurora Serverless v2 叢集

N/A

目前,Aurora Serverless v2SQL僅在版本 3 上支援「我的 Aurora」。

Aurora 全域資料庫中的叢集

若要將 Aurora My SQL 從版本 2 升級到版本 3,請遵循針對 Aurora 全域資料庫中的叢集執行就地升級的程序。在全域叢集上執行升級。Aurora 會同時升級全域資料庫中的主要叢集和所有次要叢集。

如果您使用 AWS CLI 或 RDSAPI,請呼叫指modify-global-cluster令或ModifyGlobalCluster作業而不是modify-db-clusterModifyDBCluster

如果lower_case_table_names參數已開啟,則無法執行從 Aurora 我SQL的版本 2 到版本 3 的就地升級。如需詳細資訊,請參閱主要版本升級

平行查詢叢集

您可以執行就地升級。在這種情況下,請選擇 2.09.1 或更高SQL版本的 Aurora 我的版本。

二進位日誌複寫目標的叢集

也許可以

如果二進位記錄複寫來自 Aurora My SQL 叢集,您可以執行就地升級。如果二進位記錄複寫來自 My SQL 或內部部署 My SQL DB 執行個RDS體的二進位記錄複寫,則無法執行升級。在這種情況下,您可以使用快照還原機制進行升級。

具有零資料庫執行個體的叢集

使用 AWS CLI 或 RDSAPI,您可以在沒有任何連接的資料庫執行個體的情況下建立 Aurora My SQL 叢集。以同樣的方式,您也可以從 Aurora My SQL 叢集中移除所有資料庫執行個體,同時保持叢集磁碟區中的資料完整無損。雖然叢集具有零資料庫執行個體,但您無法執行就地升級。

升級機制需要叢集中的寫入器執行個體,才能對系統資料表、資料檔案等執行轉換。在此情況下,請使用 AWS CLI 或建RDSAPI立叢集的寫入器執行個體。然後可以執行就地升級。

啟用恢復的叢集

您可以針對使用回溯功能的 Aurora 我的SQL叢集執行就地升級。不過升級之後,您無法將叢集恢復到升級前的時間。

Aurora 我SQL就地主要版本升級的運作方式

Aurora My SQL 會以多階段程序的形式執行主要版本升級。您可以檢查升級的目前狀態。某些升級步驟也會提供進度資訊。每個階段開始時,Aurora My 會SQL記錄一個事件。您可以在RDS主控台的 [事件] 頁面上檢查事件發生時的事件。如需使用事件的資訊,請參閱使用 Amazon RDS 事件通知

重要

程序開始後即會執行,直至升級成功或失敗為止。升級進行中時,無法取消升級。如果升級失敗,Aurora 會復原所有變更,且您的叢集具有相同的引擎版本、中繼資料等,與之前一樣。

升級程序包含三個階段:

  1. Aurora 會在開始升級程序之前執行一系列的預先檢查。Aurora 在執行這些檢查時,叢集會持續執行。例如,叢集不能有任何處於準備好狀態的 XA 交易,也不能處理任何資料定義語言 (DDL) 陳述式。例如,您可能需要關閉提交特定SQL陳述式種類的應用程式。或者,您可以直接等到某些長時間執行的陳述式完成。然後再次嘗試升級。某些檢查會測試無法阻止升級,但可能會使升級需要很長時間的條件。

    如果 Aurora 偵測到不符合任何必要條件,請修改事件詳細資訊中識別的條件。請遵循 Aurora 疑難排解我的SQL就地升級 中的指引。如果 Aurora 偵測到可能導致升級緩慢的條件,請規劃長期監控升級。

  2. Aurora 會使叢集離線。然後 Aurora 會執行類似的一組測試,如上一階段,以確認關閉程序中沒有出現任何新問題。如果此時 Aurora 偵測到任何可能阻止升級的條件,Aurora 會取消升級並使叢集恢復線上狀態。在這種情況下,請確認條件何時不再適用,然後再次開始升級。

  3. Aurora 會建立叢集磁碟區的快照。假設您在升級完成後,發現相容性或其他類型的問題。或者,假設您想要同時使用原始叢集和升級的叢集來執行測試。在這種情況下,您可以從此快照還原,以建立具有原始引擎版本和原始資料的新叢集。

    提示

    此快照為手動快照。不過,即使您已達到手動快照的配額,Aurora 也可以建立快照並繼續進行升級程序。此快照會永久保留 (如有需要),直到您將其刪除為止。完成所有升級後測試之後,您可以刪除此快照,將儲存費用降至最低。

  4. Aurora 會複製您的叢集磁碟區。複製是一個快速操作,不涉及複製實際的資料表資料。如果在升級期間 Aurora 遇到問題,它會從複製的叢集磁碟區還原為原始資料,並使叢集恢復線上狀態。升級期間暫時複製的磁碟區不受單一叢集磁碟區複製數目的一般限制。

  5. Aurora 會執行寫入器資料庫執行個體的正常關閉。在正常關閉期間,進行下列操作的進度事件每 15 分鐘記錄一次。您可以在RDS主控台的 [事件] 頁面上檢查事件發生時的事件。

    • Aurora 會清除舊版本資料列的還原記錄。

    • Aurora 會復原任何未遞交的交易。

  6. Aurora 會升級寫入器資料庫執行個體上的引擎版本:

    • Aurora 會在寫入器資料庫執行個體上安裝新引擎版本的二進位檔。

    • Aurora 使用寫入器資料庫執行個體將您的資料升級為 My SQL 5.7 相容格式。在此階段,Aurora 會修改系統資料表,並執行其他會影響叢集磁碟區中資料的轉換。尤其是,Aurora 會升級系統表格中的分割區中繼資料,使其與 My SQL 5.7 分割區格式相容。如果叢集中的資料表具有大量的分割區,此階段可能需要很長時間。

      如果在此階段發生任何錯誤,您可以在我的SQL錯誤日誌中找到詳細信息。在此階段開始之後,如果升級程序因任何原因失敗,Aurora 會從複製的叢集磁碟區還原該原始資料。

  7. Aurora 會升級讀取器資料庫執行個體上的引擎版本。

  8. 升級程序已完成。Aurora 會記錄最終事件,以指示升級程序已順利完成。現在,您的資料庫叢集正在執行新的主要版本。

藍/綠部署

在某些情況下,您的首要目標是立即從舊叢集切換至升級的叢集。在這種情況下,您可以使用執行舊叢集和新叢集 side-by-side的多步驟處理序。在這裡,您會將舊叢集的資料複寫到新叢集,直至您準備好接管新叢集。如需詳細資訊,請參閱 使用 Amazon RDS 藍/綠部署進行資料庫更新