企業常見痛點

時間壓力：長時間的系統停機
升級風險：擔憂資料遺失或損壞
人力成本：需要大量人工操作
技術複雜度：MySQL 5.7 到 8.0 版本差異大，升級困難

傳統升級方式 vs DMS 升級方式

傳統的升級方式與 DMS 升級方式比較

Google Cloud DMS 簡化了傳統的升級流程，為可靠、高效且低風險的資料庫升級解決方案。

以下分別以「舊版 Cloud SQL 升級方式」、「Cloud SQL 升級方式」以及「使用DMS來做Cloud SQL - MySQL升級」三個方法說明，內容包含相關概念介紹和實作步驟指南。

舊版 Cloud SQL 升級方式

需評估網路架構是否升級

網路架構

如果是2021年8月以前建置的舊網路架構，就需要考慮是否升級新的網路架構。

新舊網路架構比較

傳統與現代網路架構升級比較

網路架構升級注意事項

網路架構升級會至少會有4分鐘的Downtime。
該網路中的Cloud SQL Instance不能超過300個。
網路架構升級不支援舊版的Cloud SQL HA版本。

網路架構升級可能問題

但是一般客戶正式環境為保證高可用性，多會部屬Cloud SQL HA版本，因此如果是2021年8月以前部屬的舊版Cloud SQL HA版本，不考慮網路架構升級方案。

Cloud SQL 升級方式

Cloud SQL Enterprise Plus

Cloud SQL Enterprise Plus有另外的升級方式，在此不討論。

Cloud SQL Enterprise 本機升級

本機升級的作法注意事項(僅摘錄重點)

因為MySQL 5.7和8.0兩個版本差異過大，在升級前建議先使用MySQL原生的升級檢查工具Upgrade Checker Utility來確認該環境是否適合本機升級。
確認要本機升級，也需參考官方文件和登入MySQL，手動修改資料格式(Keyword，Characters，Foreign Key限制，稀疏資料型態等)來符合最新版本要求。
本機升級必須要有額外的記憶體空間和硬碟空間來存放轉換的Metadata和已升級的Table。
MySQL5.7和8.0的權限不同，需確認使用者權限修改部分，特別是MySQL 8.0預設的Flag是partial_revokes=ON，需在升級前修改使用者權限，確保可以正確存取資料庫名稱。
預計升級的Table數目大於512000可能會花費極長的時間，甚至會發生Timeout的錯誤。
本機升級會造成Downtime，一般Cloud SQL的Instance升級需要花費小於10分鐘，但如果Instance中包含的DB或Table數目眾多，升級可能會花費數小時。

本機升級優劣分析

本機升級雖然可以保留原本網路設定，但因為升級過程需要手動進入DB內部修改資料，手動修改容易出錯，且Downtime時間長，不建議在正式環境使用該方式做升級。

Cloud SQL Enterprise 以搬移資料方式做升級

使用Data Migration Service (DMS)來做升級
- 會在後面章節做介紹

將資料從舊的MySQL環境手動Export出來，再Import到新版本的MySQL環境上。

新的MySQL Instance需要設定成惟讀模式。
升級過程會有Downtime發生。
升級時也需同本機升級作法一樣，需手動做資料格式調整和權限調整。
不推薦在正式環境使用，因為手動操作容易出錯，且Downtime時間長。

使用DMS來做Cloud SQL - MySQL升級

使用DMS的步驟與限制

設定Source

如果Source是使用Private IP的Cloud SQL，倘若Private IP是在非RFC 1918 Address IP範圍的位址，需要設定Authorized Networks。
在搬移前，須先停止所有Data Definition Language (DDL)的寫入操作。
確保Source DB不能包含使用者以DEFINER定義的Metadata。
如果來源資料庫有引用 mysql、performance_schema、information_schema、ndbinfo 或 sys等Schema的物件，請確保複本資料庫也包含這些系統預設Schema。
必須設定Server-id為1或大於1。
如果Source端已經配置有Read Replica， Source端的global transaction ID (GTID)日誌檔設定GTID_MODE必需要設定為ON。
目的地端已經啟動Private Service Connect，或目的地端已經包含資料的資料庫就不支援使用DMS做搬移。

建立Source Connection Profile
建立Migration Job到新的Destination Instance
Configure Connectivity

DMS提供三種連線模式設定：IP allowlists，Reverse SSH tunnel using a cloud-hosted VM，和VPC peering等三種。
IP allowlists: 考慮採用外網連接模式，最簡單，適合Source資料庫在GCP外部。
Reverse SSH tunnel using a cloud-hosted VM: 考慮採用安全連線但卻沒有VPC Network可以連接到Cloud SQL。
VPC Peering: 考慮採用內網連接模式，需採用Private Service Access的內網連線方式。

建立Migration Job

使用 Database Migration Service 的步驟

選擇Source端的Cloud SQL Instance

Source端資料庫的資料

Source端為Cloud SQL - MySQL 5.7
Private IP位址為10.0.0.2
資料庫Root的密碼為password

建立Migration Jobs

在搜尋BAR中搜尋database migration，選擇出現結果的第一個 - Database Migration。

點選Database Migration>>Migration Jobs，選擇CREATE MIGRATION JOB。

設定Migration Jobs

設定Migration Job Name和Migration Job ID。
選擇Source DB Engine - Cloud SQL - MySQL。
Destination Region為asia-east1(Taiwan)。
Migration Job Type為one-time
選擇SAVE & CONTINUE

建立Source Connection Profile

點選CREATE A CONNECTION PROFILE

INSTANCE ID填寫Source端資料庫的Instance ID。
Connection Profile Name和Connection Profile ID填寫方便自己管理的名稱(舉例如source-mysql-57-test)。
Hostname or IP Address填寫Source端資料庫的Private IP位址。
Username和Password填寫Source端資料庫的管理者帳號-Rorrt和Root密碼。
點選CREATE。

點選Database Migration >>Connection Profiles，點選CREATE PROFILE

確認無誤後，點選SAVE & CONTINUE。

建立Destination資料庫

Type of destination instance選擇New instance
Destination Instance ID輸入預計的目的地資料庫名稱 - test-mysql-57-80
Password輸入預計目的地端資料庫使用者 - Root的密碼。
Database version選擇要升級的版本。

根據需要的情境選擇合適的Cloud SQL edtion。在此為了方便測試，選擇Enterprise版本和Single Zone。

網路勾選Private IP和選擇合適的Private Connection。

根據需求選擇合適的Instance Type和Storage Size。在這邊為簡化測試步驟，僅用最小參數設定。

點選CREATE & SAVE來建立一個空的目的地端資料庫。建立目的地端資料庫需要一段時間。從Cloud SQL上可發現有目的地端資料庫正在建立。

設定Connectivity方法

Connectivity method設定為Source和destination are using private IP。
VPC網路選擇該環境使用的VPC網路，在此為了簡便設定採用default VPC。

點選CONFIGURE & CONTINUE。

測試和Create Migration Job

點選TEST JOB，倘若TEST JOB成功，再按CREATE JOB

啟動Migration Job

等Migration Job建立好，就勾選想執行的Migration Job，並且按Start來開始做資料庫Migration。
可以從Status觀察目前Migration的狀態，直到Status變成Completed，就表示Migration Job完成。

【GCP教學】使用 Google Cloud DMS 升級 Cloud SQL MySQL (5.7 to 8.0) 最佳實踐，DMS強在哪？