從 Aurora 遷移至 MySQL 適用的 Cloud SQL 之前，需要考量的重要事項
Amazon 的 AWS 和 Google Cloud 都提供雲端式的全代管 MySQL 資料庫服務。這兩個雲端服務供應商在各自的預設設定中各有其特色和差異。從某個供應商遷移至另一個供應商之後，這些差異可能會導致非預期的效能或作業問題。本文將概略說明這類遷移作業期間可能發生的問題，以及建議採用的解決方案。請特別注意，我們將重點說明將 MySQL 資料庫服務從 Aurora MySQL 遷移至 MySQL 適用的 Cloud SQL。
遷移注意事項
字元集：效能問題
Aurora 使用預設的字元集伺服器 latin1 (直到 MySQL v5.7 為止)。這與 MySQL 適用的 Cloud SQL 資料庫、資料表、儲存的程序和函式預設設定不同。在遷移期間，以 utf8 做為預設字元集來建立。這可能會導致效能問題。
例如，使用者最終可能會使用以 latin1 字元集建立資料表，且使用 Cloud SQL 預設 utf8 字元集建立已儲存程序或函式。在這類情況下，如果儲存的程序或函式預期變數為 utf8 參數，並將該變數與資料欄值 (使用 latin1 字元集) 進行比較，就會造成效能問題，因為兩種不同字元集的比較和定序。
您可以使用下列指令來檢查處理常式的字元集：
|
mysql> select ROUTINE_NAME, ROUTINE_SCHEMA, CHARACTER_SET_NAME, COLLATION_NAME from information_schema.ROUTINES; |
如果您使用 Aurora 中的預設字元集 (至 v5.7)，也就是使用 latin1，則在匯入資料之前，應將 Cloud SQL 中的預設字元集從 utf8 變更為 latin1。
另一種解決方法是將所有內容變更為 utf8，不過在這個案例中，使用者應測試完整的應用程式和資料集，因為變更字元集可能會產生非預期的資料呈現。
使用者可以透過以下方式，在旗標區段下方編輯 Cloud SQL 執行個體的這項設定。
字元集：不相容問題
Aurora MySQL 5.7 有大量定序 (例如字元集 utf8mb4 適用的 utf8mb4_0900_ai_ci)，目前僅適用於 MySQL 適用的 Cloud SQL 8.0。如果您使用任何這類定序，並且匯入 MySQL 適用的 Cloud SQL 5.7 中的資料，系統會顯示以下錯誤訊息「Error 'Character set '#255' is not a compiled character set」(錯誤字元集 '#255' 不是經過編譯的字元集)。
解決方法是在 MySQL 5.7 版中，將這些定序變更為可用的定序。
儲存引擎：所有資料表都必須在 InnoDB 中
與 Aurora 不同，MySQL 適用的 Cloud SQL 不支援 MyISAM 引擎。從 Aurora 遷移至 Cloud SQL 之前，建議先將所有資料表轉換為 InnoDB。
如果 InnoDB 之外的引擎中有資料表，使用者可以使用「ALTER」指令變更資料表的引擎：
|
mysql> alter table table_1 engine='Innodb' ; Query OK, 0 rows affected (2.89 sec) Records: 0 Duplicates: 0 Warnings: 0 |
注意：查詢時間取決於資料表大小，而且可能會鎖定同一資料表的其他作業。您也可以使用線上結構定義變更工具，例如 pt-online-schema-change 或 gh-ost，在不封鎖其他作業的情況下修改資料表。
讀取連線的端點
在 Aurora 中，使用者可以在單一端點後方設定多個讀取器，但 MySQL 適用的 Cloud SQL 使用者沒有這項立即可用的功能。MySQL 適用的 Cloud SQL 中，每個 read-replica 都有自己的 IP，而使用者必須使用如 ProxySQL 等，將流量分配至多個唯讀備用資源執行個體。
Aurora 沒有變更緩衝區
變更緩衝區是一種特殊的資料結構，可以在次要索引頁面不在緩衝區集區中時，快取這些頁面變更，並於稍後其他讀取作業載入這些頁面至緩衝區集區時，加以合併。詳情請參閱變更緩衝區。
以工作負載在含有次要索引的資料表上執行大量寫入作業而言，Aurora 的執行速度可能比 MySQL 適用的 Cloud SQL 慢，後者會使用預設的 InnoDB 變更緩衝區功能，將更新延後至稍晚的工作階段。使用者應根據應用程式工作負載來衡量效能。
查詢快取可能會影響效能
查詢快取會將選取指令及其結果儲存在中繼儲存空間層中。如果稍後收到相同的陳述式，伺服器就會從查詢快取檢查並擷取結果，而不會再次執行該指令。系統會在多個工作階段之間共用查詢快取，因此所有工作階段都能從其他工作階段已執行的陳述式所快取的結果中受益。進一步瞭解查詢快取。
Aurora 預設會啟用查詢快取，不過 MySQL Community 已停用 5.7 版中的查詢快取，並在 8.0 版本中完全移除該快取，MySQL 適用的 Cloud SQL 也是如此。如果您的查詢依賴 Aurora 的查詢快取功能，在 MySQL 適用的 Cloud SQL 的效能可能會有所不同。建議您比較使用 Aurora 的執行時間，藉此測試 MySQL 適用的 Cloud SQL 中的查詢效能。
複製機制可能會影響效能
針對一個區域內的唯讀備用資源，Aurora 採用的叢集磁碟區概念，會在該區域的三個可用區中複製資料。Aurora 中的複製延遲通常不到 100 毫秒，因為同一個資料庫叢集中的主要與備用資源，都看到叢集磁碟區中的資料顯示為單一邏輯磁碟區。此外，針對跨區域唯讀備用資源，Aurora 在各地區使用以磁碟為基礎的資料同步處理，而非執行二進位記錄檔的複製作業。
簡單來說，複製作業會由 Aurora 的儲存空間層處理，而在 MySQL 適用的 Cloud SQL 中，標準複製機制會將二進位記錄檔轉移至備用資源執行個體，並在使用 MySQL 執行個體的備用資源中重播這些記錄檔。我們可以在 Cloud SQL 中設定平行複製功能，藉此改善複製效能。請參閱設定平行複製功能的詳細資料。
雖然複製延遲取決於應用程式以及主要執行個體和備用資源執行個體之間的網路變更的資料量，但大多數應用程式都可以正常運作，而且在 Aurora 和 MySQL 適用的 Cloud SQL 中都不會有明顯的延遲。不過，如果應用程式需要大量寫入，且應用程式正在讀取備用資源，那麼建議您先在 AWS Aurora 和 MySQL 適用的 Cloud SQL 中對複製延遲進行基準測試，再進行遷移。
以全域交易 ID (GTID) 為基礎的複製功能
MySQL 適用的 Cloud SQL 使用 GTID 複製功能，這點與使用磁碟式資料同步處理的 AWS Aurora 不同。如果應用程式工作流程依附於上述任一功能，使用者應在遷移前檢查下列 GTID 的限制，並在應用程式中執行所有必要的變更：
- 使用 GTID 型複製功能時，不允許使用 CREATE TABLE ... SELECT 陳述式。
- 交易、程序、函式和觸發條件中不支援 CREATE TEMPORARY TABLE 和 DROP TEMPORARY TABLE 陳述式。您可以在 GTID 啟用時使用這些陳述式，但只能在任何交易以外使用，而且只能使用 autocommit=1。
如要進一步瞭解以 GTID 為基礎的限制，請參閱 GTID 的限制。
相關產品和服務
Google Cloud 提供代管的 MySQL 資料庫，可滿足您的業務需求，包括淘汰地端部署資料中心、執行軟體式服務 (SaaS) 應用程式，以及遷移核心業務系統等。
