TiDB Binlog 常見問題

本文介紹 TiDB Binlog 使用過程中的常見問題及解決方案。

開啟 binog 對 TiDB 的性能有何影響？對于查詢無影響。

對于有寫入或更新數據的事務有一點性能影響。延遲上，在 Prewrite 階段要并發寫一條 p-binlog 成功后才可以提交事務，一般寫 binlog 比 KV Prewrite 快，所以不會增加延遲。可以在 Pump 的監控面板看到寫 binlog 的響應時間。

TiDB Binlog 的同步延遲一般為多少？

TiDB Binlog 的同步延遲為秒級別，在非業務高峰時延遲一般為 3 秒左右。

Drainer 同步下游 TiDB/MySQL 的帳號需要哪些權限？

Drainer 同步帳號需要有如下權限：Insert

Update

Delete

Create

Drop

Alter

Execute

Index

Select

Pump 磁盤快滿了怎么辦？

確認 GC 正常：確認 pump 監控面板 gc_tso 時間是否與配置一致。

如 gc 正常以下調整可以降低單個 pump 需要的空間大小：調整 pump GC 參數減少保留數據天數。

添加 pump 結點。

Drainer 同步中斷怎么辦？

使用以下 binlogctl 命令查看 Pump 狀態是否正常，以及是否全部非 offline 狀態的 Pump 都在正常運行。Copy

binlogctl -cmd pumps

查看 Drainer 監控與日志是否有對應報錯，根據具體問題進行處理。

Drainer 同步下游 TiDB/MySQL 慢怎么辦？

特別關注以下監控項：通過 Drainer 監控 drainer event，可以看到 Drainer 當前每秒同步 Insert/Update/Delete 事件到下游的速度。

通過 Drainer 監控 sql query time，可以看到 Drainer 在下游執行 SQL 的響應時間。

同步慢的可能原因與解決方案：同步的數據庫包含沒有主鍵或者唯一索引的表，需要給表加上主鍵。

Drainer 與下游之間延遲大，可以調大 Drainer worker-count 參數(跨機房同步建議將 Drainer 部署在下游)。

下游負載不高，可以嘗試調大 Drainer worker-count 參數。

假如有一個 Pump crash 了會怎樣？

Drainer 會因為獲取不到這個 Pump 的數據沒法同步數據到下游。如果這個 Pump 能恢復，Drainer 就能恢復同步。

如果 Pump 沒法恢復，可采用以下方式進行處理：Drainer 獲取到的數據會丟失這個 Pump 上的數據，下游跟上游數據會不一致，需要重新做全量 + 增量同步。具體步驟如下：停止當前 Drainer。

上游做全量備份。

清理掉下游數據，包括 checkpoint 表 tidb_binlog.checkpoint。

使用上游的全量備份恢復下游數據。

部署 Drainer，使用 initialCommitTs= {從全量備份獲取快照的時間戳}。

什么是 checkpoint？

Checkpoint 記錄了 Drainer 同步到下游的 commit-ts，Drainer 重啟時可以讀取 checkpoint 接著從對應 commit-ts 同步數據到下游。

Drainer 日志 ["write save point"] [ts=411222863322546177] 表示保存對應時間戳的 checkpoint。

下游類型不同，checkpoint 的保存方式也不同：下游 MySQL/TiDB 保存在 tidb_binlog.checkpoint 表。

下游 kafka/file 保存在對應配置目錄里的文件。

因為 kafka/file 的數據內容包含了 commit-ts，所以如果 checkpoint 丟失，可以消費下游最新的一條數據看寫到下游數據的最新 commit-ts。

Drainer 啟動的時候會去讀取 checkpoint，如果讀取不到，就會使用配置的 initial-commit-ts 做為初次啟動開始的同步時間點。

Drainer 機器發生故障，下游數據還在，如何在新機器上重新部署 Drainer？

如果下游數據還在，只要保證能從對應 checkpoint 接著同步即可。

假如 checkpoint 還在，可采用以下方式進行處理：部署新的 Drainer 并啟動即可(參考 checkpoint 介紹，Drainer 可以讀取 checkpoint 接著同步)。

假如 checkpoint 不在，可以如下處理：獲取之前 Drainer 的 checkpoint commit-ts，做為新部署 Drainer 的 initial-commit-ts 配置來部署新的 Drainer。

如何用全量 + binlog 備份文件來恢復一個集群？清理集群數據并使用全部備份恢復數據。

使用 reparo 設置 start-tso = {全量備份文件快照時間戳+1}，end-ts = 0(或者指定時間點)，恢復到備份文件最新的數據。

主從同步開啟 ignore-error 觸發 critical error 后如何重新部署？

TiDB 配置開啟 ignore-error 寫 binlog 失敗后觸發 critical error 告警，后續都不會再寫 binlog，所以會有 binlog 數據丟失。如果要恢復同步，需要如下處理：停止當前 Drainer。

重啟觸發 critical error 的 tidb-server 實例重新開始寫 binlog(觸發 critical error 后不會再寫 binlog 到 pump)。

上游做全量備份。

清理掉下游數據包括 checkpoint 表 tidb_binlog.checkpoint。

使用上游的全量備份恢復下游。

部署 Drainer，使用 initialCommitTs= {從全量備份獲取快照的時間戳}。

同步時出現上游數據庫支持但是下游數據庫執行會出錯的 DDL，應該怎么辦？查看 drainer.log 日志，查找 exec failed 找到 Drainer 退出前最后一條執行失敗的 DDL。

將 DDL 改為下游兼容支持的版本，在下游數據庫中手動執行。

查看 drainer.log 日志，查找執行失敗的 DDL 語句，可以查詢到該 DDL 的 commit-ts。例如：

[2020/05/21 09:51:58.019 +08:00] [INFO] [syncer.go:398] ["add ddl item to syncer, you can add this commit ts to `ignore-txn-commit-ts` to skip this ddl if needed"] [sql="ALTER TABLE `test` ADD INDEX (`index1`)"] ["commit ts"=416815754209656834]。

編輯 drainer.toml 配置文件，在 ignore-txn-commit-ts 項中添加該 commit-ts，重啟 Drainer。

在絕大部分情況下，TiDB 和 MySQL 的語句都是兼容的。用戶需要注意的是上下游的 sql_mode 應當保持一致。

在什么情況下暫停和下線 Pump/Drainer？

首先需要通過以下內容來了解 Pump/Drainer 的狀態定義和啟動、退出的流程。

暫停主要針對臨時需要停止服務的場景，例如：版本升級：停止進程后使用新的 binary 啟動服務。

服務器維護：需要對服務器進行停機維護。退出進程，等維護完成后重啟服務。

下線主要針對永久(或長時間)不再使用該服務的場景，例如：Pump 縮容：不再需要那么多 Pump 服務了，所以下線部分服務。

同步任務取消：不再需要將數據同步到某個下游，所以下線對應的 Drainer。

服務器遷移：需要將服務遷移到其他服務器。下線服務，在新的服務器上重新部署。

可以通過哪些方式暫停 Pump/Drainer？直接 kill 進程。注意：

不能使用 kill -9 命令，否則 Pump/Drainer 無法對信號進行處理。

如果 Pump/Drainer 運行在前臺，則可以通過按下 Ctrl+C 來暫停。

使用 binlogctl 的 pause-pump 或 pause-drainer 命令。

可以使用 binlogctl 的 update-pump/update-drainer 命令來下線 Pump/Drainer 服務嗎？

不可以。使用 update-pump/update-drainer 命令會直接修改 PD 中保存的狀態信息，并且不會通知 Pump/Drainer 做相應的操作。使用不當時，可能會干擾數據同步，某些情況下還可能會造成數據不一致的嚴重后果。例如：當 Pump 正常運行或者處于暫停狀態時，如果使用 update-pump 將該 Pump 設置為 offline，那么 Drainer 會放棄獲取處于 offline 狀態的 Pump 的 binlog 數據，導致該 Pump 最新的 binlog 數據沒有同步到 Drainer，造成上下游數據不一致。

當 Drainer 正常運行時，使用 update-drainer 命令將該 Drainer 設置為 offline。如果這時啟動一個 Pump 節點，Pump 只會通知 online 狀態的 Drainer，導致該 Drainer 沒有及時獲取到該 Pump 的 binlog 數據，造成上下游數據不一致。

可以使用 binlogctl 的 update-pump/update-drainer 命令來暫停 Pump/Drainer 服務嗎？

不可以。update-pump/update-drainer 命令直接修改 PD 中保存的狀態信息。執行這個命令并不會通知 Pump/Drainer 做相應的操作，而且使用不當會使數據同步中斷，甚至造成數據丟失。

什么情況下使用 binlogctl 的 update-pump 命令設置 Pump 狀態為 paused？

在某些異常情況下，Pump 沒有正確維護自己的狀態，實際上狀態應該為 paused。這時可以使用 update-pump 對狀態進行修正，例如：Pump 異常退出(可能由 panic 或者誤操作執行 kill -9 命令直接 kill 掉進程導致)，Pump 保存在 PD 中的狀態仍然為 online。如果暫時不需要重啟 Pump 恢復服務，可以使用 update-pump 把該 Pump 狀態設置為 paused，避免對 TiDB 寫 binlog 和 Drainer 獲取 binlog 造成干擾。

什么情況下使用 binlogctl 的 update-drainer 命令設置 Drainer 狀態為 paused？

在某些異常情況下，Drainer 沒有正確維護自己的狀態，，對數據同步造成了影響，實際上狀態應該為 paused。這時可以使用 update-drainer 對狀態進行修正，例如：Drainer 異常退出(出現 panic 直接退出進程，或者誤操作執行 kill -9 命令直接 kill 掉進程)，Drainer 保存在 PD 中的狀態仍然為 online。當 Pump 啟動時無法正常通知該 Drainer(報錯 notify drainer ...)，導致 Pump 無法正常運行。這個時候可以使用 update-drainer 將 Drainer 狀態更新為 paused，再啟動 Pump。

可以通過哪些方式下線 Pump/Drainer？

目前只可以使用 binlogctl 的 offline-pump 和 offline-drainer 命令來下線 Pump 和 Drainer。

什么情況下使用 binlogctl 的 update-pump 命令設置 Pump 狀態為 offline?警告：

僅在可以容忍 binlog 數據丟失、上下游數據不一致或者確認不再需要使用該 Pump 存儲的 binlog 數據的情況下，才能使用 update-pump 修改 Pump 狀態為 offline。

可以使用 update-pump 修改 Pump 狀態為 offline 的情況有：在某些情況下，Pump 異常退出進程，且無法恢復服務，同步就會中斷。如果希望恢復同步且可以容忍部分 binlog 數據丟失，可以使用 update-pump 命令將該 Pump 狀態設置為 offline，則 Drainer 會放棄拉取該 Pump 的 binlog 然后繼續同步數據。

有從歷史任務遺留下來且不再使用的 Pump 且進程已經退出(例如測試使用的服務)，之后不再需要使用該服務，使用 update-pump 將該 Pump 設置為 offline。

在其他情況下一定要使用 offline-pump 命令讓 Pump 走正常的下線處理流程。

Pump 進程已經退出，且狀態為 paused，現在不想使用這個 Pump 節點了，能否用 binlogctl 的 update-pump 命令設置節點狀態為 offline？

Pump 以 paused 狀態退出進程時，不保證所有 binlog 數據被下游 Drainer 消費。所以這樣做會有上下游數據不一致的風險。正確的做法是重新啟動 Pump，然后使用 offline-pump 下線該 Pump。

什么情況下使用 binlogctl 的 update-drainer 命令設置 Drainer 狀態為 offline？有從歷史任務遺留下來且不再使用的 Drainer 且進程已經退出(例如測試使用的服務)，之后不再需要使用該服務，使用 update-drainer 將該 Drainer 設置為 offline。

可以使用 change pump、change drainer 等 SQL 操作來暫停或者下線 Pump/Drainer 服務嗎？

目前還不支持。這種 SQL 操作會直接修改 PD 中保存的狀態，在功能上等同于使用 binlogctl 的 update-pump、update-drainer 命令。如果需要暫停或者下線，仍然要使用 binlogctl。

TiDB 寫入 binlog 失敗導致 TiDB 卡住，日志中出現 listener stopped, waiting for manual stop

在 TiDB v3.0.12 以及之前，binlog 寫入失敗會導致 TiDB 報 fatal error。但是 TiDB 不會自動退出只是停止服務，看起來像服務卡住。TiDB 日志中可看到 listener stopped, waiting for manual stop。

遇到該問題需要根據具體情況判斷是什么原因導致 binlog 寫入失敗。如果是 binlog 寫入下游緩慢導致的，可以考慮擴容 Pump 或增加寫 binlog 的超時時間。

TiDB 在 v3.0.13 版本中已優化此邏輯，寫入 binlog 失敗將使事務執行失敗返回報錯，而不會導致 TiDB 卡住。

TiDB 向 Pump 寫入了重復的 binlog？

TiDB 在寫入 binlog 失敗或者超時的情況下，會重試將 binlog 寫入到下一個可用的 Pump 節點直到寫入成功。所以如果寫入到某個 Pump 節點較慢，導致 TiDB 超時(默認 15s)，此時 TiDB 判定寫入失敗并嘗試寫入下一個 Pump 節點。如果超時的 Pump 節點實際也寫入成功，則會出現同一條 binlog 被寫入到多個 Pump 節點。Drainer 在處理 binlog 的時候，會自動去重 TSO 相同的 binlog，所以這種重復的寫入對下游無感知，不會對同步邏輯產生影響。

在使用全量 + 增量方式恢復的過程中，Reparo 中斷了，可以使用日志里面最后一個 TSO 恢復同步嗎？

可以。Reparo 不會在啟動時自動開啟 safe-mode 模式，需要手動操作：Reparo 中斷后，記錄日志中最后一個 TSO，記為 checkpoint-tso。

修改 Reparo 配置文件，將配置項 start-tso 設為 checkpoint-tso + 1，將 stop-tso 設為 checkpoint-tso + 80,000,000,000(大概是 checkpoint-tso 延后 5 分鐘)，將 safe-mode 設置為 true。啟動 Reparo，Reparo 會將數據同步到 stop-tso 后自動停止。

Reparo 自動停止后，將 start-tso 設置為 checkpoint tso + 80,000,000,001，將 stop-tso 設置為 0，將 safe-mode 設為 false。啟動 Reparo 繼續同步。

總結

以上是生活随笔為你收集整理的og-bin=mysql-bin_TiDB Binlog 常见问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。