如要遷移至 Cloud SQL 上的 MySQL，有多種方式可供選擇。特定來源的遷移策略取決於多項因素，包括資料庫大小、預期停機時間，以及執行遷移作業的工程師是否有經驗。接著來看看幾種最常見的遷移策略。

如要遷移大小僅有幾 GB，或內含靜態資料的小型資料庫，最簡單的方法就是透過 mysqldump 公用程式來 dump 資料庫。請先將 dump 檔案上傳至 Cloud Storage，然後按照「使用 SQL dump 檔案匯出及匯入」一文提供的操作說明，將 dump 檔案匯入 Cloud SQL 執行個體。

由於傾印檔案含有邏輯 SQL 陳述式，因此這種做法的優點是在資料載入 Cloud Storage 之前，可以先編輯傾印檔案。不過，考量到某些 Cloud SQL 限制，建議避免在 dump 檔案中加入任何可能導致匯入作業中斷的項目，詳情請參閱「匯入資料及匯出資料的最佳做法」一文。

如要遷移 MySQL 的許多執行個體，或是執行規模較大的遷移作業時，採用資料庫遷移服務 (DMS)是較理想的選擇。這項服務提供多樣化的遷移路徑，包括同質與異質遷移至 MySQL 的路徑，並且支援目的地為 SQL Server 和 PostgreSQL 的遷移作業。

對大部分中大型資料庫的遷移作業來說，使用 DMS 應能滿足需求。不適合使用 DMS 的情況包括：大型資料庫 (例如規模高達數 TB)，或是 MySQL 工程師具備複製技術知識，且偏好更精細地控管使用原生 MySQL 複製功能的遷移程序。

如果遷移期間優先考量的是盡可能縮短停機時間，而且團隊中有經驗豐富的 MySQL 工程師，就可以考慮使用原生二進位記錄式複製功能，從外部來源 (ES) 複製資料。這種方法會運用 Cloud Storage 匯入等方式匯入資料庫的基準快照。

接下來，您可以使用 Cloud SQL 執行個體上提供的一組預先建立並儲存的程序，設定 MySQL 複製作業的來源執行個體和目標 Cloud SQL 執行個體。如需完整操作說明，請參閱「使用自訂匯入功能設定大型外部資料庫的複製作業」一文。

使用二進位記錄式複製功能進行遷移時，關鍵在於來源執行個體上的二進位記錄必須維持可供存取狀態，直到目標 Cloud SQL 執行個體不再需要為止。如果是在地端部署或自行管理的環境中執行 MySQL，可以設定 expire_logs_days 等參數來控制二進位記錄的清除作業。不過，其他雲端服務供應商代管服務對二進位記錄的保留可能有其限制。

舉例來說，Amazon Relational Database Service (RDS) 可讓您透過名為 mysql.rds_set_configuration 的預存程序來設定二進位記錄保留功能。最長可保留七天。對於從 RDS 移至 Cloud SQL 這類中小規模的遷移作業，大部分七天就已足夠。在這種情況下，使用者可以運用有完善記錄的程序，包括建立代管 RDS 副本。然後，採取一些措施來「破壞」複製作業，例如將副本變更為可寫入狀態並刪除資料列，或是在主要資源上插入某種「毒藥」交易，藉此在二進位記錄中產生相關項目並中斷複製作業。只要備用資源仍需要二進位記錄，RDS 自動化作業就不會將其清除 (雖然可能有 30 天的整體上限，但之後 RDS 就會「終止」中斷的複製流程)。

另一種解決方法是使用 mysqlbinlog 用戶端將二進位記錄下載至其他中介 MySQL 執行個體，以免二進位記錄過早清除。例如，RDS 中有一個名為 mysql.rds_set_configuration 的預存程序，能讓您以小時為單位來設定保留期限，確保二進位記錄在主機上留存足夠時間以供下載。在這種情況下，就不需要執行 MySQL 執行個體做為中介，因為任何類似 MySQL 執行個體的伺服器 (例如「二進位記錄伺服器」)，都可以用來儲存和轉送二進位記錄。

由於 MySQL 支援多個可插式儲存引擎，因此在最熱門的關聯式資料庫系統當中獨樹一格。MySQL 一開始支援名稱為 MyISAM 的單一儲存引擎，在 MySQL 8.0 之前，大多數系統資料表都使用這個儲存空間引擎。不過，由於 MyISAM 當時無法支援交易，一旦發生系統突然關閉或資料庫異常終止的情況，可能就無法維持正常運作。

此後，由於 InnoDB 採用具有當機安全機制的架構，並可支援交易，因此成為大部分 MySQL 使用者資料表實際使用的儲存引擎。但在 MySQL 社群中，包括 on-premises 和其他雲端服務供應商環境中，也常見到其他儲存引擎，其中包括：

• ARCHIVE：以高壓縮格式儲存資料，以供封存作業使用
• CSV：以半形逗號分隔格式 (CSV) 儲存資料，用於記錄一般和速度緩慢的查詢記錄資料表
• MEMORY：將資料表儲存在記憶體中

以 Cloud SQL 來說，必須搭配有交易及當機防範功能的儲存引擎，才能支援複製和時間點復原等提供附加價值的功能。因此，所有遷移至 Cloud SQL 的使用者資料表都必須使用 InnoDB 儲存引擎，或是在遷移過程中轉換至 InnoDB。

使用 MySQL 原生複製功能從外部來源複製資料到 Cloud SQL 時，這一點特別重要。雖然 Cloud SQL 不允許使用者透過資料定義語言 (DDL) 指令 (例如 CREATE TABLE)，直接在 Cloud SQL 執行個體上建立 MyISAM 資料表，但 MyISAM 資料表目前可從外部來源複製到 Cloud SQL。

不過，這些 MyISAM 資料表匯入 Cloud SQL 後，有可能在複製、時間點復原和容錯移轉等作業期間造成穩定性和可靠性問題。因此，建議您在執行遷移作業前，將所有 MyISAM 使用者資料表轉換為 InnoDB。

以下查詢會列出所有非系統 MyISAM 資料表。

MySQL 適用的 Cloud SQL 是一項代管服務，不允許使用者帳戶具備 SUPER 權限。這與大多數安裝於 on-premises 環境的 MySQL 不同，後者允許具備這項權限的超級使用者存在。同樣地，大多數其他雲端服務供應商都不會在代管的 MySQL 環境中提供這項 SUPER 權限。

無論在何種情況下，Cloud SQL 使用者都會獲得名為「root’@’%」的預設 MySQL 使用者角色，並獲授予大多數 MySQL 提供的權限，但不包括會影響 Google 管理服務的權限 (例如先前提到的 SUPER，以及 FILE 和 SHUTDOWN 等)。如要進一步瞭解 Cloud SQL 所提供的使用權限，請參閱 MySQL 使用者說明文件。

準備遷移時，請檢查來源執行個體中的所有使用者帳戶。舉例來說，您可以對每位使用者執行 SHOW GRANTS 指令，檢查現有的權限組合，並查看在 Cloud SQL 中是否有任何限制。此外，Percona 提供的 pt-show-grants 工具也可以列出授權內容。

遷移具有 DEFINER 屬性的資料庫物件時，Cloud SQL 的使用者權限限制可能會影響遷移作業。發生這種情況的通常是預存程序、觸發條件、使用者定義函式和檢視畫面。如果來源執行個體上的資料庫物件定義者是具有 Cloud SQL 不支援權限的使用者，在遷移期間或之後就可能會發生這個問題。

舉例來說，預存程序可能具有超級權限定義者，以便執行 SQL 指令，例如變更全域變數，但 Cloud SQL 不允許這項操作。在這種情況下，您可能需要重新編寫預存程序程式碼，或在其他遷移步驟中分別遷移預存程序這類非資料表物件。

請參閱相關說明文件中標題為「包含中繼資料且其中有 DEFINER 子句的 MySQL 匯入和遷移工作」的章節，進一步瞭解資料庫物件定義者子句的其他相關問題。

由於前述的使用者權限限制，使用者無法原生呼叫 SET GLOBAL 指令來變更資料庫參數。不過，Cloud SQL 提供一組預先定義的「旗標」，只要透過 UI 控制台、gcloud CLI 和 REST API 修改這些旗標，即可變更參數。

請參閱公開說明文件中標題為「支援的旗標」的章節，查看支援的 MySQL 適用的 Cloud SQL 旗標完整清單。遷移至 Cloud SQL 之前，請先查看支援的旗標清單，以及目前在來源環境中使用的旗標清單。舉例來說，有一項最佳做法就是建立一個 CPU 與記憶體設定與來源執行個體類似的測試用 Cloud SQL 執行個體，然後同時在來源和 Cloud SQL 執行個體上執行 SSHOW GLOBAL VARIABLES，最後再比較兩者之間的差異。

on-premises 或雲端服務供應商環境中常見旗標的設定可能與 MySQL 適用的 Cloud SQL 不同，其中包括：

• 字元集和定序設定，例如 character_set_server 和 collation_server。預設值會因安裝版本而異，因而導致儲存空間和效能方面的差異。例如 latin1 和 utf8。
• 二進位記錄設定，例如 binlog_format。Cloud SQL 目前僅支援二進位記錄檔中的資料列式記錄。
• 進階複製設定。舉例來說，Cloud SQL 不支援複製篩選器參數，例如 replicate-do-table 和 replicate-do-db。
• 進階 InnoDB 設定。Cloud SQL 允許修改大部分的 InnoDB 相關參數，例如透過變更 innodb_buffer_pool_size 來調整 InnoDB 緩衝區集區大小。不過，部分精細的 InnoDB 設定無法在 Cloud SQL 中修改，或是預設值與 on-premises 或其他雲端服務供應商環境不同。