為什麼我的 AWS DMS CDC 任務在使用 MySQL 做為原始碼時,會失敗並出現 1236 錯誤?

4 分的閱讀內容
0

我正在使用 AWS Database Migration Service (AWS DMS) 將我的資料從來源 MySQL 資料庫引擎遷移到目標引擎。但是任務失敗並出現 1236 錯誤。如何對此問題進行疑難排解?

簡短描述

有了 AWS DMS,您可以執行一次性遷移,也可以複寫進行中的變更以保持來源和目標同步。為了從來源資料庫讀取進行中的變更,AWS DMS 會使用特定引擎的 API 動作以讀取來源引擎交易日誌中的變更。使用 MySQL 做為來源時,AWS DMS 會讀取資料列基礎的二進位日誌 (binlog) 中的變更。然後,AWS DMS 會將這些變更遷移到目標。

錯誤 1236 是由二進位日誌問題引起的。因此,在進行疑難排解之前,請確定所有二進位日誌參數都已正確設定為支援 AWS DMS CDC。如需詳細資訊,請參閱使用自我管理的 MySQL 相容資料庫做為 AWS DMS 來源使用 AWS 受管 MySQL 相容資料庫做為 AWS DMS 來源

解決方案

根據錯誤的根本原因,按照以下步驟操作。

錯誤 1236 (二進位日誌索引檔案中找不到第一個日誌檔案名稱) 讀取 binlog

任務日誌中的錯誤:

[SOURCE_CAPTURE  ]I: Setting position in binlog 'mysql-bin-changelog.014448' at 119624570  (mysql_endpoint_capture.c:886)
[SOURCE_CAPTURE  ]I: Position was set in binlog 'mysql-bin-changelog.014448' at 119624570  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]E: Error 1236 (Could not find first log file name in binary log index file) reading binlog [1020493] 
[TASK_MANAGER    ]I: Task - ABCDXXXXXXXXXXXXXX is in ERROR state, updating starting status to AR_NOT_APPLICABLE

此錯誤表示 AWS DMS 用以複寫資料變更到目標的二進位日誌,已從來源 MySQL 資料庫中清除。發生此情況有兩個原因:

  • 二進位日誌保留期間太短。
  • AWS DMS 任務因問題而卡住或已停止。

執行這些命令以確認二進位日誌是否可用。

列出所有二進位日誌檔案

mysql> SHOW BINARY LOGS;

列出目前二進位日誌檔案和位置

mysql> SHOW MASTER STATUS;

若要解決此錯誤,請先檢閱來源 MySQL 資料庫上的二進位日誌保留期間。如有需要,請增加保留期間。重新啟動 AWS DMS 任務以再次執行完全載入階段。

請視您使用的執行個體類型,依照下列步驟執行。

自我管理 MySQL 資料庫 - 內部部署或 Amazon Elastic Compute Cloud (Amazon EC2)

檢閱 expire_logs_days 以檢查二進位日誌保留期間。在全域層級將此參數設定為 1 或更大值是最佳實務。

AWS 受管 MySQL 資料庫 - 適用於 MySQL 的 Amazon Relational Database Service (Amazon RDS) 或 Amazon Aurora MySQL 相容版

1.    執行mysql.rds_show_configuration 命令以檢查 MySQL 資料庫上設定的 binlog 保留時間:

mysql> call mysql.rds_show_configuration;

2.    若要將日誌保留期間提高到 24 小時,請執行 mysql.rds_set_configuration 命令:

mysql> call mysql.rds_set_configuration('binlog retention hours', 24);

錯誤 1236 (日誌事件條目超過 max_allowed_packet;增加主節點上的 max_allowed_packet;…)

任務日誌中的錯誤:

[SOURCE_CAPTURE  ]I:  Position was set in binlog 'mysql-bin.056367' at 787323674  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]D:  net_safe_read error 1236 (log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event 'mysql-bin.056367' at 787323674, the last event read from '/mnt/data/logs/mysql-bin.056367' at 123, the last byte read from '/mnt/data/logs/mysql-bin.056367' at 787323693.)  (mysql_endpoint_capture.c:1119)
[SOURCE_CAPTURE  ]I:  Error 1236 (log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event 'mysql-bin.056367' at 787323674, the last event read from '/mnt/data/logs/mysql-bin.056367' at 123, the last byte read from '/mnt/data/logs/mysql-bin.056367' at 787323693.) reading binlog. Try reconnect  (mysql_endpoint_capture.c:1123)

此錯誤有兩種可能的原因:

  1. 來源的 max_allowed_packet 值小於來源上的 binlog 事件大小。
  2. 來源資料庫上的 binlog 已損毀。

若要解決這些問題,請依照下列步驟執行:

1.    在來源上,將 max_allowed_packet 設定為較高的值。這樣做可以排除 binlog 事件大小為錯誤的可能原因。此參數的值最多可達 1 GB。

2.如果設定較高的 max_allowed_packet 值無法解決問題,則來源上的 binlog 可能已損毀。錯誤訊息包含下列文字:

"第一個事件 '/mnt/data/logs/mysql-bin.056367' 在 123,最後一個事件在 787323693 從 '/mnt/data/logs/mysql-bin.056367' 中讀取"

因此,執行以下命令以檢查 mysql-bin.056367 是否損毀:

1.    檢查 binlog 是否存在

mysql> SHOW BINARY LOGS;

2.    檢視二進位日誌中的事件

mysql> SHOW BINLOG EVENTS IN '<binlog file>' FROM <position>;

3.    下載二進位日誌

mysql> MYSQLBINLOG;

錯誤 1236 (binlog 在事件中間截斷;考慮主節點上的磁碟空間不足;…)

任務日誌中的錯誤:

[SOURCE_CAPTURE ]I: Read next binary log event failed; net_safe_read error 1236 (binlog truncated in the middle of event; consider out of disk space on master; the first event 'mysql-bin-changelog.017672' at 486, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.017672' at 125, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.017672' at 4756.) (mysql_endpoint_capture.c:1069)
[SORTER ]I: Transaction consistency reached (sorter_transaction.c:347)
[TASK_MANAGER ]I: Starting replication now (replicationtask.c:2774)
[TASK_MANAGER ]I: Task - MGLVRIRUJH6FE2GP6F7SW46BPBW6YKF2JUJPSVY is in RUNNING state, updating starting status to AR_RUNNING (repository.c:5110)

此錯誤有兩個主要原因:

  1. 主伺服器上有個 sync_binlog != 1。這表示二進位日誌事件可能不會在磁碟上同步處理。
  2. 來源資料庫上的 binlog 已損毀。

若要解決此錯誤:

1.    檢查來源上的 sync_binlog 參數值。

2.    修改 sync_binlog 的值,並將其設定為 1

3.    重新啟動任務。

注意:如果 sync_binlog 參數已設定為 1,請使用先前詳細說明錯誤 1236 的步驟檢閱二進位日誌是否損毀 (日誌事件條目超過 max_allowed_packet;增加主節點上的 max_allowed_packet;…)

錯誤 1236 (客戶端請求主節點從不可能的位置開始複寫…)

任務日誌中的錯誤:

[SOURCE_CAPTURE  ]I:  Position was set in binlog 'mysql-bin-changelog.007989' at 1631  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]I:  Read next binary log event failed; net_safe_read error 1236 (Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.007989' at 1631, the last event read from 'mysql-bin-changelog.007989' at 4, the last byte read from 'mysql-bin-changelog.007989' at 4.)  (mysql_endpoint_capture.c:1053)
[SOURCE_CAPTURE  ]D:  Error reading binary log. [1020493]  (mysql_endpoint_capture.c:3995)
[SOURCE_CAPTURE  ]E:  Error 1236 (Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.007989' at 1631, the last event read from 'mysql-bin-changelog.007989' at 4, the last byte read from 'mysql-bin-changelog.007989' at 4.) reading binlog events [1020493]  (mysql_endpoint_capture.c:1074)

如果來源 MySQL 資料庫伺服器意外停止,通常會發生此錯誤。這可能是硬體故障的結果,如磁碟錯誤或電源中斷。

若要解決此錯誤,請根據您的 AWS DMS 任務類型執行下列操作:

  • 完整載入和 CDC 任務 - 重新啟動 AWS DMS 任務。
  • 僅限 CDC 任務 - 從下一個二進位日誌位置啟動 AWS DMS 任務

錯誤 1236 (客戶端請求主節點從位置 > 檔案大小開始複寫)

任務日誌中的錯誤:

[SOURCE_CAPTURE  ]I:  Position was set in binlog 'binlog.000012' at 2179  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]I:  Read next binary log event failed; net_safe_read error 1236 (Client requested master to start replication from position > file size)  (mysql_endpoint_capture.c:1052

此錯誤可能是由加密的二進位日誌造成的。如果您的來源 MySQL 資料庫執行 MySQL 8.0 版,且二進位日誌已加密,則 AWS DMS 無法在任務初始化時讀取日誌。因此,AWS DMS 會記錄此錯誤。開啟二進位日誌加密時,AWS DMS 不支援使用 MySQL 8.0 做為來源的 CDC 複寫。

1.    檢查您的 MySQL 版本:

mysql> SELECT VERSION();

2.    檢查 binlog_encryption 是否為 ON (開啟):

mysql> SELECT * FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'binlog_encryption';

3.    關閉 binlog 加密:

mysql> SET GLOBAL binlog_encryption = OFF;

-或-

在關閉 binlog_encryption 的情況下啟動 AWS DMS 任務,然後開啟 binlog_encryption:

mysql> SET GLOBAL binlog_encryption = ON;

相關資訊

該如何對在使用 AWS DMS 搭配 Aurora MySQL 作為來源時收到的二進位日誌記錄錯誤進行疑難排解?

AWS 官方
AWS 官方已更新 2 年前