遷移至 MySQL 適用的 Cloud SQL 的最佳做法
規劃和執行將資料庫從 MySQL 遷移至 MySQL 適用的 Cloud SQL 時，有許多要考量的事項，包括遷移資料庫的複雜程度、需要遷移的資料量及可容許的停機時間等級。其中一個考量因素是 MySQL 資料庫的來源執行個體。MySQL 的來源執行個體可透過下列任一方式託管：
- 託管於其他雲端服務供應商 (如 AWS 或 Azure) 的 MySQL 執行個體
- 在您自己的資料中心或辦公室的伺服器中託管的 MySQL 執行個體 (稱為地端部署)
本文適用於這兩種情況。
相關文章
總覽
資料庫遷移作業可分為兩種主要類型。如果是從執行 MySQL 的來源執行個體，或使用 MySQL 做為前端的資料庫 (例如 AWS Aurora for MySQL)，到在雲端的 MySQL 或 MySQL 適用的 Cloud SQL 進行遷移，則視為同質遷移。如果來源執行個體正在執行不同的資料庫 (例如 PostgreSQL、SQL Server、Oracle) 或任何其他與目的地不同的資料庫，則稱為異質遷移作業。
本文的重點在於採用同質的遷移作業，因為 MySQL 適用的 Cloud SQL 通常就是如此。本文將探討如何遷移至 MySQL 適用的 Cloud SQL、儲存引擎的考量、使用者權限及 MySQL 旗標。不過，許多秘訣和做法也同樣適用於異質遷移作業。
遷移至 MySQL 適用的 Cloud SQL 的方式
您可以透過多種方式在 Cloud SQL 上遷移至 MySQL。特定來源的遷移策略取決於多項因素，包括資料庫大小、預計停機時間，以及執行遷移作業的工程師相關經驗。讓我們來看看一些最常見的遷移策略。
Cloud Storage 匯入
如要遷移僅有 GB 規模，或包含靜態資料的小型資料庫，最簡單的方法就是透過 mysqldump 公用程式來轉儲資料庫。將傾印檔案上傳至 Cloud Storage，然後按照使用 SQL 傾印檔案匯出及匯入一文中的操作說明，將傾印檔案匯入 Cloud SQL 執行個體檔案。
由於傾印檔案含有邏輯 SQL 陳述式，因此這種做法的優點在於可以在資料載入 Cloud Storage 之前，先編輯傾印檔案。不過，考量到特定 Cloud SQL 限制，建議避免在傾印檔案中加入任何可能導致匯入作業中斷的項目，如匯入資料及匯出資料的最佳做法一節中所述。
資料庫移轉服務 (DMS)
遷移 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 自動化作業就不會清除二進位檔記錄 (不過，在 RDS「終止」故障的複製串流之前，似乎有 30 天的整體限制)。
另一種解決方法是使用 mysqlbinlog 用戶端將二進位記錄檔下載至其他中介 MySQL 執行個體，以避免過早的二進位檔記錄清除。例如，在 RDS 中，有一個名為 mysql.rds_set_configuration 的已儲存程序，允許以小時為單位設定保留期限，以確保二進位檔在主機上的留存時間長短足以供下載。在此情況下，您不需將 MySQL 執行個體作為中介系統，因為任何看起來像 MySQL 執行個體一樣的伺服器 (例如「二進位記錄檔伺服器」)，都可以用來儲存和轉寄二進位檔記錄。
儲存引擎的注意事項
MySQL 在受歡迎的關聯資料庫系統中是獨一無二的，因為它支援多個可插入的儲存引擎。MySQL 一開始支援使用稱為 MyISAM 的單一儲存引擎，在 MySQL 8.0 之前，大多數系統資料表都使用這個儲存空間引擎。然而，MyISAM 尚未支援交易，在發生系統突然關閉或資料庫異常時，就有異常終止的風險。
此後，由於 InnoDB 具有不容易受到當機影響的架構，並支援交易作業，因此成為大部分 MySQL 使用者資料表的實際儲存引擎。但在地端部署和其他雲端服務供應商中，其他的儲存引擎在 MySQL 社群中通常也很常見，包括：
就 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 權限。這與大部分地端部署安裝的 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 中不支援的全域變數。在這種情況下，您可能需要重新編寫已儲存的程序程式碼，或單獨遷移非資料表的物件 (像是已儲存的程序)。
我們的說明文件有一個名為「MySQL 的匯入和遷移工作，內含中繼資料且包含 DEFINER 子句」的章節，其中進一步說明資料庫物件定義器子句的其他相關問題。
旗標
由於前述的使用者權限限制，使用者無法在原生情況下呼叫 SET GLOBAL 指令來變更資料庫參數。Cloud SQL 會提供一組預先定義的「旗標」，您可以透過 UI 控制台、GCloud CLI 和 REST API 來修改參數。
您可以在我們標題為支援的旗標的公開說明文件中，查看支援的 MySQL 適用的 Cloud SQL 旗標完整清單。遷移至 Cloud SQL 之前，請先查看支援的旗標清單與目前在來源環境中使用的旗標清單。舉例來說，其中一項最佳做法是建立具有與來源執行個體類似的 CPU 與記憶體設定的 Cloud SQL 執行個體，並同時針對這兩個來源和 Cloud SQL 執行個體執行 SSHOW GLOBAL VARIABLES，然後比較兩者之間的差異。
在地端部署或雲端服務供應商與 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_buffer_pool_size 修改大部分 InnoDB 相關參數，例如調整 InnoDB 緩衝集區的大小。但是，有些更精細的 InnoDB 設定可能無法在 Cloud SQL 中加以修改，或是採用與地端部署或其他雲端服務供應商不同的預設值。
相關產品和服務
Google Cloud 提供代管的 MySQL 資料庫，可滿足您的業務需求，包括淘汰地端部署資料中心、執行軟體式服務 (SaaS) 應用程式，以及遷移核心業務系統等。
