診斷 MySQL 問題

遷移工作程序在執行階段可能會發生錯誤。

  • 部分錯誤 (例如來源資料庫的密碼有誤) 可以復原，也就是說，修正錯誤後，遷移作業會自動繼續。
  • 有些錯誤無法復原，例如二進位記錄檔位置遺失，這時就必須從頭開始執行遷移工作。

發生錯誤時，遷移工作狀態會變更為「Failed」，子狀態則會反映失敗前的最後狀態。

如要排解錯誤，請前往失敗的遷移工作查看錯誤，然後按照錯誤訊息中的步驟操作。

如要查看錯誤的詳細資料，請使用遷移工作中的連結前往 Cloud Monitoring。系統會篩選記錄檔，只顯示特定移轉工作的記錄。

下表列出一些問題範例和解決方法：

如果遇到這個問題... 問題可能出在... 不如說
目的地資料庫設定與用於佈建資料庫的 Terraform 設定不同。(這個問題有時也稱為設定偏移)。 遷移至 現有目的地資料庫時，資料庫遷移服務會修改目的地資料庫的特定設定，以執行遷移工作。 升級遷移工作後，您必須重新套用 Terraform 設定中使用的設定。請參閱「Terraform 設定偏移」。
錯誤訊息：Error processing table {table_name}: MySQL Error 1118 (42000): Row size too large (>8126). 使用 VARCHAR 欄的資料表可能會有超過 InnoDB (MySQL 中使用的預設儲存引擎) 允許大小上限的資料列。 如要解除遷移工作的封鎖狀態，請將資料欄轉換為 BLOB 或 TEXT，或暫時將 innodb_strict_mode 旗標設為 off。請參閱「錯誤 1118：資料列過大」。
在初始傾印階段，遷移工作失敗，並顯示下列錯誤訊息：
ERROR 1064 (42000) at {line_number}: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near {reserved_word} at {line_number}.		 在 MySQL 版本之間遷移時，會發生這個問題。 來源 MySQL 版本中的實體可能使用不允許的字詞， 因此無法移轉至目標 MySQL 版本。

舉例來說，在 MySQL 5.7 中，您可以在資料欄名稱中使用 function 一字。但在 MySQL 8.0 中，function 是保留字，因此目的地資料庫無法剖析來源。

 重新命名錯誤訊息中參照的來源資料庫物件，或將這些物件放在倒引號 (``) 中，以逸出語法。完成後，請重試遷移工作。
錯誤訊息：ERROR 1109 (42S02): Unknown table in <schema name here> 資料庫遷移服務不會遷移 mysql、performance_schema、information_schema、ndbinfo 或 sys 系統結構定義。

如果來源資料庫包含參照這些結構定義中資料表的物件，遷移工作可能會失敗。

 檢查來源資料庫，找出參照未遷移系統結構定義中資料表的物件。請參閱「ERROR 1109 (42S02): Unknown table in <schema name here>」。
錯誤訊息：Unknown table 'COLUMN_STATISTICS' in information_schema (1109) 僅適用於使用 mysqldump 手動轉儲資料庫的情境。

8 之前的 MySQL 資料庫版本沒有 COLUMN_STATISTICS 資料表。在第 8 版和更新版本中，mysqldump 公用程式預設會嘗試匯出這個資料表。資料欄不存在，因此匯出失敗。

 使用 mysqldump 時，請使用 --column-statistics=0 旗標。
錯誤訊息：Specified key was too long; max key length is 767 bytes。 來源資料庫執行個體可能已設定 innodb_large_prefix 變數。 建立目的地執行個體時，請將 innodb_large_prefix 標記設為 ON，或使用標記更新現有目的地執行個體。
錯誤訊息：Table definition has changed。 dump 期間，資料定義語言 (DDL) 有所變更。 在轉儲程序中避免變更 DDL。
錯誤訊息：While 'Loading data': Dump timeout。 連線能力問題可能導致逾時。 確認與來源資料庫的網路連線。如需範例指南，請參閱「偵錯連線能力」。
如果在傾印程序期間執行資料定義語言 (DDL) 變更，資料庫遷移服務可能會因中繼資料鎖定而停滯。 請檢查來源資料庫，確認是否有程序卡在 Waiting for table metadata lock 狀態。如果發現有這類狀態的程序，建議重新啟動遷移作業。重新啟動後，請勿在完整轉儲階段執行 DDL 變更。您可以使用 範例指令碼，確認 DDL 作業已停止。
MySQL Error 2013: (HY000): Lost connection to MySQL server during query 連線能力問題可能會導致逾時。 確認與來源資料庫的網路連線。如需範例指南，請參閱「偵錯連線能力」。
如果在傾印程序期間執行資料定義語言 (DDL) 變更，資料庫遷移服務可能會停滯在繼資料鎖定狀態。 請檢查來源資料庫，確認是否有程序卡在 Waiting for table metadata lock 狀態。如果發現有這類狀態的程序，建議重新啟動遷移作業。重新啟動後，請勿在完整傾印階段執行 DDL 變更。您可以使用 範例指令碼，確認 DDL 作業已停止。
錯誤訊息：Timeout waiting for no write traffic on source: context deadline exceeded。 連線能力問題可能會導致逾時。 確認與來源資料庫的網路連線。如需範例指引，請參閱「偵錯連線」。
如果在轉儲程序期間執行資料定義語言 (DDL) 變更，資料庫遷移服務可能會卡在中繼資料鎖定狀態。 調查來源資料庫，檢查是否有處於 Waiting for table metadata lock 狀態的程序。如果發現有這類狀態的程序，建議重新啟動遷移作業。重新啟動後，請勿在完整傾印階段執行 DDL 變更。您可以使用 範例指令碼，確認 DDL 作業已停止。
錯誤訊息：Access denied; you need (at least one of) the SUPER privilege(s) for this operation。 來源資料庫中可能有事件、檢視表、函式或程序使用超級使用者@localhost (例如 root@localhost)。Cloud SQL 不支援這項功能。 如要進一步瞭解 Cloud SQL 中的 DEFINER 使用情形，請參閱這篇文章。
錯誤訊息：Definer user 'x' does not exist. Please create the user on the replica. 副本上沒有該使用者。 進一步瞭解 Cloud SQL 中的 DEFINER 用量。
錯誤訊息：ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost。 來源資料庫中有一個DEFINER，但副本中沒有。 進一步瞭解 Cloud SQL 中的 DEFINER 用量。
錯誤訊息：Lost connection to MySQL server during query when dumping table。 來源資料庫可能無法連線，或傾印包含過大的封包。 請嘗試這些建議。
錯誤訊息：Got packet bigger than 'max_allowed_packet' bytes when dumping table。 封包大小超過設定允許的上限。 使用手動轉儲，並加上 max_allowed_packet 選項。
初始資料遷移成功，但未複製任何資料。 可能有衝突的複製旗標。 檢查這些旗標設定。
初始資料遷移作業成功，但資料複製作業在一段時間後停止運作。 可能的原因有很多。 請嘗試這些建議。
錯誤訊息：mysqld check failed: data disk is full。 目的地執行個體的資料磁碟已滿。 增加目的地執行個體的磁碟大小。您可以手動增加磁碟大小，也可以啟用儲存空間自動增加功能。
無法連線至來源資料庫執行個體。 來源資料庫執行個體與目的地執行個體之間的連線發生問題。 請按照偵錯連線能力文章中的步驟進行。
從代管資料庫 (Amazon RDS/Aurora) 遷移作業未啟動。 如果從沒有 SUPERUSER 權限的代管來源資料庫遷移，遷移作業開始時會短暫停機。 請按照這篇文章的步驟操作。
來源資料庫的二進位記錄檔設定有誤。 Binlog 定義有誤。 如果是 MySQL 持續遷移工作，請務必遵循必要的 binlog 定義。
找不到 dump 檔案。 資料庫遷移服務找不到您提供的 dump 檔案。 如果遷移工作在指定位置找不到傾印檔案，就可能發生這種情況。
  1. 請檢查傾印路徑，確保其中有正確的檔案，或變更路徑。
  2. 如果變更路徑，請使用 PATCH 要求，確保工作使用該路徑。
  3. 重新啟動遷移工作。
二進位記錄位置遺失，因此無法繼續複製。 二進位記錄檔位置遺失，無法繼續執行遷移工作。 如果複製程序長時間暫停，導致二進位記錄檔位置遺失，就可能發生這項錯誤。遷移工作的暫停時間不應接近二進位記錄檔保留期限。重新啟動遷移工作。
遷移至 現有的目的地執行個體時，會收到下列錯誤訊息： The destination instance contains existing data or user defined entities (for example databases, tables, or functions). You can only migrate to empty instances. Clear your destination instance and retry the migration job. 目的地 Cloud SQL 執行個體含有額外資料。您只能遷移至空白的現有執行個體。請參閱「已知限制」。 將目的地執行個體升級為讀取/寫入執行個體、移除多餘資料，然後重新嘗試遷移工作。請參閱「清除現有目的地執行個體中的額外資料」。
來源和目的地資料庫版本不相容，因此無法執行遷移工作。 提供的來源資料庫版本與目的地資料庫版本不相容。 請確認目的地資料庫版本與來源目的地版本相同，或比來源目的地版本高一個主要版本，然後建立新的遷移工作。
錯誤訊息：Unable to connect to source database server. 資料庫遷移服務無法連線至來源資料庫伺服器。 請確認來源和目的地資料庫執行個體可以相互通訊，並完成定義遷移工作設定時顯示的所有必要先決條件。
錯誤訊息：Timeout waiting for no write traffic on source. 從沒有 SUPERUSER 權限的代管來源資料庫遷移時，遷移作業開始時會短暫停機。 請按照「從沒有 SUPERUSER 權限的 RDS MySQL 遷移」一文中的步驟操作。
錯誤訊息：ERROR 1146 (42S02) at line {line_number}: Table '{table_name}' doesn't exist. 來源資料庫的 lower_case_table_names 旗標值，可能與目的地 Cloud SQL 執行個體的旗標值不一致。 將 Cloud SQL 執行個體的旗標值設為與來源資料庫的旗標值相符。
錯誤訊息：ERROR 1109 (42S02) at line {line_number}: Unknown table '{table}' in {database}. 來源資料庫中的某些物件 (例如檢視表、函式、預存程序或觸發條件) 參照的資料表已不存在於資料庫中。 請檢查這些物件是否存在。如果是，請從來源資料庫中捨棄物件，或將物件參照的資料表新增至來源資料庫。
錯誤訊息：ERROR 1045: Access denied for user '{user_name}'@'{replica_IP}' (using password: YES)". Check if MySQL replication user and password are correct. Not attempting further retries. 您為來源執行個體提供的密碼不正確。或者，來源執行個體強制使用 SSL 連線，但遷移工作未設為使用 SSL 憑證。

使用 mysql 用戶端，確認來源執行個體的使用者名稱、密碼和 SSL 設定是否正確。

如果來源執行個體是 Cloud SQL，請參閱「要求使用 SSL/TLS」，確認 TCP 連線是否需要 SSL/TLS。

複製延遲時間持續偏高。

副本的寫入負載過高，無法處理。如果副本上的 MySQL 適用的 Cloud SQL 執行緒無法跟上 I/O 執行緒，就會發生複製作業延遲。某些類型的查詢或工作負載可能會導致特定結構定義出現暫時或永久的高複製延遲。複製延遲的常見原因如下：

  • 在副本上執行速度緩慢的查詢。找出並修正這些問題。
  • 強烈建議所有資料表都具備不重複的主鍵。如果資料表沒有這個索引鍵，每次更新都會導致副本完整掃描資料表，進而造成複製作業延遲。
  • 由於備用資源會累積大量更新，因此 DELETE ... WHERE field < 50000000 等查詢會造成以資料列為準的複製延遲。

可能的解決方法包括：

錯誤訊息：'Character set '#255' is not a compiled character set and is not specified in the '/usr/share/mysql/charsets/Index.xml' file' on query. 來源資料庫可能使用所選 Cloud SQL 副本不支援的字元集或定序。例如 AWS Aurora 2.x 版與 MySQL 5.7 相容，不過，這個版本支援 utf8mb4_0900_as_ci 校對，但 MySQL 適用的 Cloud SQL 5.7 不支援。
  • 如果遷移作業在完整轉儲階段失敗，請檢查來源資料表定義，確認是否使用不支援的字元集或定序。如果可以，請更新為支援的字元集或定序。
  • 如果在 CDC 階段遷移失敗，請檢查副本狀態，找出導致遷移失敗的二進位記錄檔，並檢查來源資料庫和應用程式，找出使用字元集或排序規則的 SQL 陳述式。如果可以，請更新為支援的字元集或定序。

錯誤 1108：列大小過大

如果資料表中的資料欄儲存長度可變的字串，資料列可能會超過 InnoDB 的預設最大資料列大小。

建議做法

調整來源資料表結構定義

只要您對超過最大列大小限制的資料表執行任何 INSERT 陳述式，這個問題就會再次發生。為避免日後發生問題，建議您先調整資料表，再重新嘗試遷移：

  • 執行下列查詢，將資料表 ROW_FORMAT 變更為 DYNAMIC 或 COMPRESSED：
    ALTER TABLE TABLE_NAME ROW_FORMAT=FORMAT_NAME;
    地點：
    • TABLE_NAME 是資料列超過大小上限的資料表名稱
    • FORMAT_NAME 為 DYNAMIC 或 COMPRESSED
    例如： 
    ALTER TABLE mytable ROW_FORMAT=DYNAMIC;
  • 將資料列資料轉換為 BLOB 或 TEXT。其中一種方法是使用 CONVERT() 函式。
停用 InnoDB 嚴格模式

如果無法調整來源資料表結構定義，可以暫時停用 InnoDB 驗證，完成遷移工作。請注意，日後嘗試寫入資料庫時，問題可能會再次發生，因此建議您在可行時調整資料表結構定義。

如要暫時停用 InnoDB 驗證，以便完成遷移工作，請按照下列步驟操作：

如果...接下來…
如果遷移至新的目的地執行個體
  1. 重新建立遷移工作。
  2. 在「定義目的地」步驟的結尾，按一下「顯示選用設定」。
  3. 在「Flags」部分，選取 innodb_strict_mode 標記，並將其設為 Off。
  4. 遷移完成後，請將 innodb_strict_mode 旗標設為 On。請參閱 MySQL 適用的 Cloud SQL 說明文件中的「設定資料庫旗標」。
如果遷移至現有的目的地執行個體
  1. 在 Cloud SQL 中，前往目的地執行個體，並將 innodb_strict_mode 旗標設為 Off。請參閱 MySQL 適用的 Cloud SQL 說明文件中的「設定資料庫旗標」。
  2. 重新建立遷移工作。
  3. 遷移完成後，請將 innodb_strict_mode 旗標設為 On。請參閱 MySQL 適用的 Cloud SQL 說明文件中的「設定資料庫旗標」。

清除現有目的地執行個體中的額外資料

遷移至 現有目的地執行個體時，會收到下列錯誤訊息： The destination instance contains existing data or user defined entities (for example databases, tables, or functions). You can only migrate to empty instances. Clear your destination instance and retry the migration job.

如果目的地執行個體含有額外資料，就可能發生這個問題。 只能遷移至空白的現有執行個體。請參閱「已知限制」。

建議做法

請按照下列步驟，清除目的地執行個體中的多餘資料，然後重新啟動遷移工作：

  1. 停止遷移工作。
  2. 此時，目的地 Cloud SQL 執行個體會處於 read-only 模式。升級目的地執行個體，取得寫入權限。
  3. 連線至目的地 Cloud SQL 執行個體。
  4. 從目的地執行個體資料庫中移除多餘資料。目的地只能包含系統設定資料。目的地資料庫不得包含使用者資料 (例如資料表)。您可以在資料庫中執行不同的 SQL 陳述式，找出非系統資料，例如：
    SELECT schema_name FROM information_schema.SCHEMATA
WHERE schema_name NOT IN ('information_schema', 'sys', 'performance_schema', 'mysql');
  5. 啟動遷移工作。

Terraform 設定偏移

遷移至 現有目的地資料庫時，資料庫遷移服務會修改目的地資料庫的特定設定，以執行遷移工作。如果是以 Terraform 佈建的資料庫，這種互動可能會導致設定漂移，也就是實際目的地資料庫設定與 Terraform 檔案中設定的不同。

試試這些建議

遷移工作執行時，請勿嘗試重新套用 Terraform 設定。升級目的地資料庫後，您可以放心調整必要設定。資料庫遷移服務會對目的地 Cloud SQL 執行個體進行下列修改： 如果 Terraform 設定包含上述任何功能的設定，就可能發生設定偏移。如需修正目的地資料庫設定，請等待遷移工作完成，並升級目的地資料庫。接著，請按照下列步驟操作： 1. 執行 `terraform plan` 指令，預覽修改內容。 1. 執行 `terraform apply` 指令，重新調整目的地資料庫設定。

ERROR 1109 (42S02): Unknown table in <schema name here>

遷移工作失敗，並顯示以下訊息： ERROR 1109 (42S02): Unknown table in <schema name here> ，例如：ERROR 1109 (42S02) at line X: Unknown table 'GLOBAL_STATUS' in information_schema。

問題可能出在

資料庫遷移服務不會遷移 mysql、performance_schema、information_schema、ndbinfo 或 sys 系統結構定義 (請參閱已知限制)。如果來源資料庫包含參照這些結構定義中資料表的物件，遷移工作可能會失敗。

試試這些建議

請檢查來源資料庫，找出參照系統結構定義中資料表的物件。在來源資料庫執行下列查詢：
# Query to check routines or functions definitions.
SELECT ROUTINE_SCHEMA, ROUTINE_NAME FROM information_schema.routines
WHERE ROUTINE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND ROUTINE_DEFINITION like '%OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE%'

# Query to check view definitions.
SELECT TABLE_SCHEMA, TABLE_NAME FROM information_schema.views
WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND view_definition like '%OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE%'

# Query to check trigger definitions.
SELECT TRIGGER_SCHEMA, TRIGGER_NAME FROM information_schema.TRIGGERS
WHERE TRIGGER_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND event_object_table = 'OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE'

# Query to check constraint definitions.
SELECT TABLE_SCHEMA, TABLE_NAME
FROM information_schema.KEY_COLUMN_USAGE
WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'ndbinfo', 'performance_schema', 'sys')
AND REFERENCED_TABLE_NAME = 'OBJECT_NAME_REPORTED_IN_THE_ERROR_MESSAGE'
 如果這些查詢傳回任何結果，請考慮刪除相關程式碼物件，然後再次執行遷移作業。

information_schema 中有不明資料表「COLUMN_STATISTICS」

使用 mysqldump 公用程式 8 以上版本匯出早於 8 的 MySQL 資料庫版本時，會發生 Unknown table 'COLUMN_STATISTICS' in information_schema (1109) 錯誤。

問題可能出在

8 之前的 MySQL 資料庫版本沒有 COLUMN_STATISTICS 資料表。在第 8 版以上，mysqldump 公用程式會預設嘗試匯出這個表格。資料欄不存在，因此匯出失敗。

試試這些建議

在 mysqldump 指令中加入 --column-statistics=0 旗標，即可從匯出內容中移除 COLUMN_STATISTICS 表格。詳情請參閱「使用 mysqldump 匯出 MySQL 資料庫」。

指定的鍵過長，鍵長度上限為 767 個位元組

系統顯示錯誤訊息 Specified key was too long; max key length is 767 bytes.

問題可能出在

來源資料庫可能已設定 innodb_large_prefix 變數。這樣一來，索引鍵前置字元長度就能超過 767 個位元組。MySQL 5.6 的預設值為 OFF。

試試這些建議

建立目的地資料庫時，請將 innodb_large_prefix 旗標設為 ON，或使用該旗標更新現有的目的地資料庫。

資料表定義已變更

畫面上顯示 Table definition has changed 錯誤。

問題可能出在

轉儲期間有 DDL 變更。

試試這些建議

在傾印程序期間，請勿修改資料表或執行任何其他 DDL 變更。您可以使用指令碼驗證 DDL 作業是否已停止。

存取遭拒；您需要 (至少一項) SUPER 權限才能執行這項作業

您會看到錯誤 Access denied; you need (at least one of) the SUPER privilege(s) for this operation。

問題可能在於

來源資料庫中可能有事件、檢視表、函式或程序使用超級使用者@localhost (例如 root@localhost)。Cloud SQL 不支援這項功能。

建議做法

如要瞭解如何遷移含有 DEFINER 子句的資料庫，請參閱這份文件。

錯誤訊息：Definer user 'x' does not exist. Please create the user on the replica.

畫面會顯示 Definer user 'x' does not exist. Please create the user on the replica. 錯誤

問題可能出在

根本原因是來源資料庫中含有 DEFINER 子句的使用者，在副本資料庫中不存在。

建議做法

請參閱這份文件，瞭解如何遷移含有 DEFINER 子句的資料庫。您可能需要在副本資料庫中建立使用者。

錯誤訊息：ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost

您會看到錯誤 ERROR 1045 (28000) at line {line_number}: Access denied for user 'cloudsqlimport'@'localhost。

問題可能在於

根本原因是來源資料庫中含有 DEFINER 子句的使用者不存在於副本資料庫中，且該使用者在來源資料庫的物件定義中交叉參照。

試試這些建議

請參閱這份文件，瞭解如何遷移含有 DEFINER 子句的資料庫。您可能需要在副本資料庫中建立一或多位使用者。

傾印資料表時，查詢期間與 MySQL 伺服器的連線中斷

您會看到錯誤 Lost connection to MySQL server during query when dumping table。

問題可能在於

  • 來源資料庫執行個體可能無法從目的地執行個體連線。
  • 來源資料庫可能含有大型 blob 或長字串的資料表，因此必須在來源資料庫中將 max_allowed_packet 設為較大的數字。

建議做法

  • 確認來源資料庫執行個體已啟動且可連線。
  • 在遷移工作中設定 max-allowed-packet 標記，然後重新啟動遷移工作。或者，您也可以使用 max_allowed_packet 選項產生手動傾印，傾印資料並透過 dump 檔案遷移。
  • 增加 max_allowed_packet 時，很可能需要調整來源資料庫的 net_read_timeout 和 net_write_timeout 設定 (一般來說，應增加設定值，直到連線錯誤停止為止)。

轉儲資料表時，封包大小超過「max_allowed_packet」位元組

您會看到錯誤 Got packet bigger than 'max_allowed_packet' bytes when dumping table。

問題可能在於

封包大小超過設定允許的上限。

建議做法

使用手動轉儲建立遷移工作，並搭配 max_allowed_packet 選項轉儲資料，然後使用 dump 檔案進行遷移。

沒有正在複製的資料

初始資料遷移作業已順利完成，但系統未複製任何資料。

問題可能在於

根本原因可能是來源資料庫有複製標記，導致部分或所有資料庫變更未複製。

建議做法

請確認 binlog-do-db、binlog-ignore-db、replicate-do-db 或 replicate-ignore-db 等複製旗標的設定方式不會相互衝突。
在來源資料庫上執行 show master status 指令，查看目前的設定。

初始資料遷移作業成功，但資料複製作業在一段時間後停止運作

初始資料遷移作業成功，但資料複製作業過一段時間後停止運作。

問題可能出在

這個問題可能有許多根本原因。

試試這些建議

  • 在 Cloud Monitoring 中查看目的地執行個體的複製指標。
  • 您可以在 Cloud Logging 的 mysql.err 記錄檔中，找到 MySQL IO 執行緒或 SQL 執行緒的錯誤。
  • 連線至目的地執行個體時，也可能會發生錯誤。執行 SHOW REPLICA STATUS 指令，並在輸出內容中檢查下列欄位：
    • Replica_IO_Running
    • Replica_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error

    注意：SHOW REPLICA STATUS 是 MySQL 8.0.22 中引入的別名。如果是舊版 (MySQL 5.7、MySQL 8.0)，請使用 status 指令的舊別名。詳情請參閱 MySQL 說明文件中的狀態陳述式。

    如果收到 fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file' in Last_IO_Error 錯誤，可能是因為來源執行個體的二進位記錄檔保留設定不足。

    如果收到 error connecting to master 'USER_NAME@SOURCE_HOST:SOURCE_PORT' - retry-time: RETRY_TIME retries: RETRIES 錯誤訊息，可能是因為連線能力或驗證問題，導致目的地執行個體無法重新連線至來源。

mysqld 檢查失敗：資料磁碟已滿

畫面上顯示 mysqld check failed: data disk is full 錯誤。

問題可能在於

目的地執行個體的資料磁碟可能已滿。

試試這些建議

增加目的地執行個體的磁碟大小。

無法連線至來源資料庫

無法連線至來源資料庫。

問題可能在於

來源資料庫執行個體與目的地執行個體之間的連線發生問題。

試試這些建議

請按照偵錯連線能力文章中的步驟。

無法從代管資料庫 (Amazon RDS/Aurora) 遷移

無法啟動遷移工作。

問題可能在於

如果從沒有 SUPERUSER 權限的代管來源資料庫遷移，遷移作業開始時會短暫停機。

建議做法

  • 如為 Amazon RDS，請按照這篇文章的步驟操作。
  • 如為 Amazon Aurora，請按照這篇文章的步驟操作。

來源資料庫的二進位記錄檔設定有誤

您會看到錯誤訊息，指出二進位記錄檔有問題。

問題可能出在

如果來源資料庫的 binlog 設定不正確，MySQL 連續遷移工作就可能發生這種情況。

試試這些建議

請務必按照這裡的步驟操作。

無法讀取提供的轉儲檔

您會看到錯誤訊息，指出傾印檔案有問題。

問題可能在於

DMS 找不到您提供的 dump 檔案。

試試這些建議

  1. 請檢查傾印路徑，確保其中有正確的檔案，或變更路徑
  2. 如果變更路徑，請使用 PATCH 要求，確保工作使用該路徑。
  3. 重新啟動遷移工作。

無法繼續複製，因為 binlog 位置已遺失

遺失 binlog 位置。

問題可能出在

如果複製程序長時間暫停，導致二進位記錄檔位置遺失，就可能發生這項錯誤。請勿暫停遷移工作，以免時間接近二進位記錄檔保留期限。

建議做法

重新啟動遷移工作。

來源和目的地資料庫版本不相容，因此無法執行遷移工作

來源和目的地資料庫版本不支援這種組合。

問題可能出在

提供的來源資料庫版本與目的地資料庫版本不相容。

試試這些建議

請確認目標資料庫版本與來源目標版本相同，或高出一個主要版本，然後建立新的遷移工作。

無法連線至來源資料庫伺服器

畫面上顯示 Unable to connect to source database server 錯誤。

問題可能在於

資料庫遷移服務無法連線至來源資料庫伺服器。

建議做法

確認來源和目的地資料庫執行個體可以相互通訊。接著，請確認您已完成定義遷移工作設定時顯示的所有必要條件。

Cloud SQL 目的地執行個體磁碟用量降至零

遷移期間磁碟用量突然降至零。

問題可能出在

匯入初始資料時可能會失敗。發生這種情況時，遷移程序會嘗試再次載入資料。這個程序會先清除目的地執行個體上的現有資料 (這就是您看到磁碟用量降至零的原因)，然後嘗試重新載入資料。

建議做法

前往「Logs Explorer」，從資源清單中選取目的地執行個體。尋找類似的記錄訊息： DUMP_STAGE(RETRY): Attempt .../...: import failed: error..."; Clearing database and trying again." 找出 import failed: 文字後的訊息，然後嘗試解決根本問題。