已知限制

選擇將資料庫遷移至 Cloud SQL 之前，請先瞭解這個遷移情境的已知限制。

注意：您也可以使用 Google Cloud Migration Center 找出功能支援方面的落差。請參閱 Migration Center 說明文件中的「 探索及匯入資料庫」。

使用 MySQL 資料庫做為來源時，已知限制包括：

• 如要遷移加密資料庫，您必須將加密金鑰提供給資料庫遷移服務。資料庫遷移服務支援從加密的 Amazon Aurora 或 Amazon RDS 資料庫遷移資料，因為這些資料庫會在服務中以透明方式處理解密。詳情請參閱「 加密 Amazon Aurora 資源」、「 加密 Amazon RDS 資源」和「 設定客戶自行管理的加密金鑰 (CMEK)」。

• 不支援使用 Percona XtraBackup 實體備份檔案遷移至 MySQL 5.6、MySQL 8.4 或 MySQL 9.7。

• 從 MySQL 8.0 遷移至 MySQL 8.4，以及從 MySQL 8.4 遷移至 MySQL 9.7：

  • 目的地資料庫必須將 local_infile 旗標設為 ON。
  • 來源執行個體上的專用遷移帳戶不得具備 BACKUP_ADMIN 權限。

  相關章節也會說明這些考量事項，例如「設定來源資料庫」頁面。

• 跨主要 MySQL 版本遷移時 (例如從 MySQL 8.0 遷移至 MySQL 8.4)，您需要解決可能的不相容問題，確保遷移作業順利進行，不會發生資料一致性問題。

  準備跨版本遷移時，請查看 MySQL 適用的 Cloud SQL 支援的功能，以及目標主要版本的版本資訊，判斷需要解決哪些不相容問題。

  • MySQL 9.7
  • MySQL 8.4
  • MySQL 8.0
  • MySQL 5.7

• 在完整資料傾印階段，您無法在來源資料庫上執行任何資料定義語言 (DDL) 作業 (例如 ALTER TABLE、DROP TABLE、TRUNCATE TABLE)。在完整轉儲階段執行這些作業，可能會導致中繼資料死結，造成遷移程序失敗 (出現 Table definition has changed 錯誤) 或停止回應 (並回報逾時錯誤，例如 ERROR: While 'Loading data': Dump timeout 或 MySQL Error 2013 (HY000): Lost connection to MySQL server during query)。您可以在 CDC 階段對來源資料庫執行 DDL 變更。詳情請參閱疑難排解部分的下列項目：

  • Table definition has changed
  • While 'Loading data': dump timeout
  • MySQL Error 2013: Lost connection to MySQL server during query
  • Timeout waiting for no write traffic on the source: context deadline exceeded

• 如果來源是 Amazon RDS MySQL、Amazon Aurora MySQL，或未授予 SUPERUSER 權限的來源，則須執行額外步驟才能成功遷移，包括在來源上短暫停止寫入。詳情請參閱「設定 Amazon RDS 的來源資料庫」和「Amazon Aurora 專屬」章節。

• 資料庫遷移服務無法從 Amazon Aurora 唯讀副本執行個體或 Oracle Cloud Infrastructure (OCI) MySQL 唯讀副本執行個體遷移資料，因為系統無法從執行個體擷取二進位記錄檔。如要進一步瞭解 Amazon Aurora，請參閱這個專屬章節。

• 從自行管理的 MySQL 唯讀副本遷移時，系統不支援 GTID。 您必須使用二進位記錄檔和位置式複製功能。詳情請參閱「 遷移類型和階段」。

• MySQL 系統資料庫不會在伺服器遷移作業中一併遷移，因此使用者帳戶、登入和角色資訊不會包含在內。

• 雖然您可以選取要遷移的特定資料庫，但使用資料庫遷移服務遷移時，無法篩選或選取資料庫中的個別資料庫物件 (例如特定資料表、檢視表或預存程序)。系統會從各個所選資料庫遷移所有 InnoDB 資料表和物件，但下列系統結構定義除外：mysql、performance_schema、information_schema 和 sys。開始遷移前，請確認來源資料庫不含參照這些結構定義中資料表的物件。否則遷移作業可能會失敗，並顯示 ERROR 1109 (42S02): Unknown table in <schema name here> 訊息。請參閱「設定來源資料庫」和「診斷問題」。

• 遷移期間，目的地 Cloud SQL 資料庫會處於唯讀模式，防止資料庫遭到修改，以免遷移程序中斷或影響資料完整性。目的地升級後，就會變成可寫入。

• 資料庫遷移服務與 MariaDB 不相容。

• 您必須將二進位記錄格式設為 ROW。如果將二進位記錄檔設為其他格式 (例如 STATEMENT 或 MIXED)，可能會導致複製作業失敗。例如，使用 LOAD DATA IN FILE 陳述式。

  進一步瞭解 STATEMENT 或 MIXED 格式的這項限制。

• 如果您使用自己的 dump 檔案建立連續遷移工作，請勿使用 MySQL 5.7.36 版的 mysqldump 公用程式。詳情請參閱 MySQL 說明文件中的錯誤 #105761。

• InnoDB 是 Cloud SQL 唯一支援的儲存引擎。使用 MyISAM 遷移可能會導致資料不一致，因此需要驗證資料。如需將資料表從 MyISAM 轉換為 InnoDB 的說明，請參閱 MySQL 說明文件。

• Private Service Connect 介面連線方法 僅支援遷移至現有目的地執行個體。 如要使用私人 IP 連線，並遷移至新的目的地執行個體，請使用虛擬私有雲對等互連。

資料轉儲平行處理注意事項

資料轉儲平行處理級別可讓您使用高效能轉儲機制，從 MySQL 資料庫遷移資料，大幅提升遷移速度。使用資料傾印平行處理程度時，請注意下列事項：

• 只有在遷移至 MySQL 5.7、8.0、8.4 或 9.7 版時，才能使用資料轉儲平行處理功能。

• 在資料傾印作業開始時，資料庫遷移服務會短暫鎖定來源資料庫，導致暫時無法寫入資料。鎖定時間長度取決於來源資料庫中的資料表數量：

  資料表數量	約略鎖定時間
  100	1 秒
  10K	9 秒
  5 萬	49 秒

注意： 如果無法鎖定來源資料庫，請改用唯讀副本做為來源資料庫。如要瞭解如何從 Amazon RDS 的唯讀副本遷移，請參閱「從 RDS MySQL 遷移」。

遷移至現有目的地執行個體的限制

• 現有的目的地執行個體只能包含預設系統資料庫，這些資料庫會在您建立目的地執行個體時自動設定。不支援遷移至含有使用者資料 (例如系統結構定義中的資料表或資料庫) 的現有目的地執行個體。

  如果現有目的地執行個體中的額外資料導致問題，請清除目的地執行個體中的資料庫，然後重新嘗試遷移工作。請參閱 從現有目的地執行個體清除額外資料。

• 每個目的地執行個體只能設定一項遷移工作。
• 您只能遷移至獨立 Cloud SQL 執行個體。不支援遷移至外部伺服器副本。
• 如要遷移至具有唯讀副本的 Cloud SQL 執行個體，來源執行個體必須啟用全域交易 ID (GTID) 記錄功能。
• 您無法使用 MySQL 適用的 Cloud SQL 唯讀副本做為遷移目的地執行個體。
• Terraform 使用者：資料庫遷移服務會修改目的地執行個體的備份和復原設定。這可能會導致目的地執行個體設定與您用於佈建的 Terraform 設定不同。如果遇到這個問題，請按照「診斷問題」一文中的指南操作。

配額

• 無論何時均可存在多達 2,000 個連線設定檔和 1,000 個遷移工作。如要騰出空間，可以刪除遷移工作 (包括已完成的遷移工作) 和連線設定檔。