診斷 MySQL 問題

透過集合功能整理內容 你可以依據偏好儲存及分類內容。

排解錯誤

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

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

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

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

如要查看錯誤的詳細資訊，請透過遷移工作的連結前往 Cloud Monitoring。系統會將記錄檔篩選為特定遷移工作。

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

錯誤 1108：資料列大小過大

建議做法

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

遷移至 現有的目的地執行個體時，您會收到下列錯誤訊息： 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 設定偏移

建議做法

• 備份設定已設為預設值。
• 時間點復原功能會重設為預設值。

錯誤 1109 (42S02)：<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 公用程式會預設嘗試匯出這個資料表。由於資料欄不存在，因此匯出作業失敗。

建議做法

將 --column-statistics=0 標記新增至 mysqldump 指令，即可從匯出內容中移除 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 選項產生手動傾印 ，以便傾印資料並透過傾印檔案進行遷移。
• 增加 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 選項的手動轉儲建立遷移工作，以便轉儲資料並使用轉儲檔案進行遷移。

沒有任何資料正在複製

初始資料遷移作業成功，但沒有任何資料正在複製。

問題可能出在：

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

建議做法

請確認複製旗標 (例如 binlog-do-db、binlog-ignore-db、replicate-do-db 或 replicate-ignore-db) 並未以衝突的方式設定。
在來源資料庫上執行 show master status 指令，查看目前的設定。

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

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

問題可能出在：

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

建議做法

• 在 Cloud Monitoring UI 中查看目的地執行個體的複製指標。
• 您可以在 mysql.err 記錄檔的 Cloud Logging 中，查看 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 錯誤，可能是因為來源執行個體的 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，請按照這篇文章中的步驟操作。

來源資料庫的 binlog 設定有誤

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

問題可能出在：

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

建議做法

請務必參閱這裡的定義。

無法讀取提供的傾印檔案

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

問題可能出在：

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

建議做法

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

由於 binlog 位置遺失，因此無法繼續複製

已遺失 binlog 位置。

問題可能出在：

如果複製程序暫停的時間過長，就可能導致二進位記錄檔位置遺失，進而發生這項錯誤。遷移工作不應在接近二進位記錄檔保留期間的時間內暫停。

建議做法

重新啟動遷移工作。

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

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

問題可能出在：

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

建議做法

請確認目的地資料庫版本與來源相同，或比來源還要新的主要版本，然後建立新的遷移工作。

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

您會看到 Unable to connect to source database server 錯誤訊息。

問題可能出在：

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

建議做法

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

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

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

問題可能出在：

匯入完整傾印資料時可能會失敗。在這種情況下，遷移程序會嘗試執行另一次資料載入作業。這個程序會先清除目的地執行個體中的現有資料 (因此磁碟用量會降至零)，然後嘗試重新載入資料。

建議做法

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