診斷 MySQL 問題

MySQL   |  PostgreSQL   |  PostgreSQL to AlloyDB

排解錯誤

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

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

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

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

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

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

如果遇到這個問題...	可能原因如下：	不如說
目的地資料庫設定與用於佈建資料庫的 Terraform 設定不同。(這個問題有時也稱為「設定漂移」)。	遷移至 現有目的地資料庫時，資料庫遷移服務會修改目的地資料庫的特定設定，以執行遷移工作。	升級遷移工作後，您需要重新套用 Terraform 設定中使用的設定。請參閱「 Terraform 設定漂移」。
錯誤訊息：ERROR: Error executing DDL script for view {view_name} MySQL Error {1049 or 1146 or 1824}	初始傾印失敗，因為所選資料庫包含的物件會參照未選取要遷移的資料庫中的資料。	檢查後續的錯誤訊息，判斷缺少的參照物件。 如要重試遷移作業，請先將含有物件的資料庫新增至遷移工作，或移除含有參照的資料庫。
在 CDC 階段，複製作業失敗，並顯示錯誤碼 1049、1146 或 1824。	如果對下列項目執行 DDL 陳述式，就可能發生這種情況： 所選資料庫中的檢視區塊或外鍵限制參照了未選取要遷移的資料庫。 未選取資料庫中的常式或事件。	檢查後續的錯誤訊息，判斷缺少的參照物件。 如要重試遷移作業，請先將含有物件的資料庫新增至遷移工作，或移除含有參照的資料庫。
錯誤訊息：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。	在傾印程序期間，資料定義語言 (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 設定有誤。	Binlog 定義不正確。	如果是 MySQL 連續遷移工作，請務必遵循必要的二進位記錄檔定義。
找不到傾印檔案。	DMS 找不到您提供的傾印檔案。	如果遷移工作在指定位置找不到傾印檔案，就可能發生這種情況。 檢查傾印路徑，確保檔案正確無誤，或變更路徑。 如果變更路徑，請使用 PATCH 要求，確保工作使用該路徑。 重新啟動遷移工作。
由於 binlog 位置遺失，因此無法繼續複製。	二進位記錄檔位置遺失，無法繼續執行遷移工作。	如果複製程序暫停時間過長，導致二進位記錄檔位置遺失，就可能發生這項錯誤。暫停遷移工作時，請勿接近二進位記錄檔保留期限。重新啟動遷移工作。
如果遷移至 現有的目的地執行個體，您會收到下列錯誤訊息： 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 權限的代管來源資料庫遷移時，遷移作業開始時會短暫停機。	按照「從 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 等查詢會導致以資料列為準的複製作業發生延遲。	可能的解決方法包括： 如果副本是 MySQL 5.7 以上版本，請設定平行複製。 將副本的 innodb_flush_log_at_trx_commit 旗標設為 2。如要進一步瞭解此標記，請參閱「使用標記的訣竅」。 編輯 MySQL 適用的 Cloud SQL 執行個體，增加副本的大小。 減少來源資料庫的負載。 為沒有主鍵或不重複鍵的資料表，在副本上建立索引資料表。 來源資料庫中的索引資料表。這需要重新啟動遷移工作。 找出並修正來源資料庫中執行速度緩慢的查詢。
錯誤訊息：'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 副本不支援的字元集或定序。例如與 MySQL 5.7 相容的 AWS Aurora 2.x 版。不過，這個版本支援 utf8mb4_0900_as_ci 校對，但 MySQL 適用的 Cloud SQL 5.7 不支援。	如果完整傾印階段的遷移作業失敗，請檢查來源資料表定義是否使用不支援的字元集或排序規則。如果可以，請更新為支援的字元集或排序規則。 如果遷移作業在 CDC 階段失敗，請檢查副本狀態，找出導致遷移作業失敗的二進位記錄檔，並檢查來源資料庫和應用程式，找出使用字元集或排序規則的 SQL 陳述式。如果可以，請更新為支援的字元集或排序規則。
如果 innodb_data_file_path 設定的資料檔名稱不是預設名稱，或資料檔超過一個，遷移設定驗證就會失敗。	遷移驗證無法剖析 innodb_data_file_path 的非預設設定。	略過驗證並建立遷移工作。

錯誤 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 驗證，以完成遷移作業，請按照下列步驟操作：

如果...	然後...
如果遷移至新的目的地執行個體	重新建立遷移工作。 在「定義目的地」步驟的結尾，按一下「顯示選用設定」。 在「Flags」部分，選取 innodb_strict_mode 標記並設為 Off。 遷移作業完成後，請將 innodb_strict_mode 旗標設為 On。 請參閱 MySQL 適用的 Cloud SQL 說明文件中的「設定資料庫旗標」。
如果遷移至現有的目的地執行個體	在 Cloud SQL 中，前往目的地執行個體，並將 innodb_strict_mode 標記設為 Off。請參閱 MySQL 適用的 Cloud SQL 說明文件中的「設定資料庫旗標」。 重新建立遷移工作。 遷移作業完成後，請將 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 以上版本，匯出 MySQL 資料庫 8 以前的版本，就會遇到這個錯誤：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 中，檢查目的地執行個體的複寫指標。
• MySQL IO 執行緒或 SQL 執行緒的錯誤會顯示在 mysql.err 記錄檔的 Cloud Logging 中。
• 連線至目標執行個體時，也可能會發現錯誤。執行 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)，請使用狀態指令的舊別名。詳情請參閱 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 錯誤，可能是因為來源例項的 binlog 保留設定不足。

  如果收到 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，請按照這篇文章的步驟操作。

---

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

系統顯示錯誤訊息，指出二進位記錄檔有問題。

問題可能出在

如果來源資料庫的二進位記錄檔設定有誤，MySQL 連續遷移工作就可能發生這種情況。

建議做法

請務必按照這裡的定義操作。

---

無法讀取提供的傾印檔案

系統會顯示錯誤訊息，指出傾印檔案有問題。

問題可能出在

DMS 找不到您提供的傾印檔案。

建議做法

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: 文字後的訊息，然後嘗試解決根本問題。