騰訊雲實名認證 騰訊雲數據傳輸服務 DTS 增量同步階段追不上追平延遲排查
一、先把“追不上”和“追平”分清楚
很多人看到 DTS 增量同步延遲變大，就會直接說“同步慢了”。其實真正麻煩的，不是慢，而是慢到追不上。追不上，意思是源庫新增的變更速度，已經高過 DTS 消費 binlog 的速度，延遲會一直往上走；追平，則是源庫寫入壓力下降，或者 DTS 端恢復正常後，延遲開始回落，最後回到可接受範圍。兩者看起來都叫延遲，處理方式卻完全不同。
排查這類問題，不能只盯著一個“延遲秒數”。要看的是整條鏈路：源庫是不是在瘋狂寫入，是否有大事務、批量更新、DDL、長事務；網路是否穩定，帶寬是否打滿；目標庫是不是卡在鎖、索引、磁碟 IOPS 或 CPU；DTS 任務本身是否有配置上的限制。只要其中任一環節成了短板，延遲就可能持續堆積。
更重要的是，要分辨“短暫積壓”和“持續追不上”。如果延遲只是在業務高峰時抬頭，峰值過後能慢慢回落，這通常是負載波動，不一定算嚴重故障。如果延遲一路上升，哪怕源庫寫入量沒有明顯增加，也沒有回落跡象，這才是要立刻處理的信號。
二、先看數據，再下結論
排查延遲，第一步不是改配置，而是把現象看準。常見做法是把 DTS 任務狀態、增量延遲、源庫寫入量、目標庫負載放在同一時間軸上看。你會很快發現，延遲上升往往不是單點造成的，而是幾個因素疊加。
比如源庫在整點做批量更新，單次提交幾十萬行；目標庫正好在跑備份或報表查詢；這時 DTS 即便沒有報錯，也會出現消費速度跟不上產生速度的情況。再比如，源庫平時每秒幾百筆變更，一到活動開始就衝到每秒幾千筆，而目標庫沒有相應的容量預留，延遲就會像水位一樣越漲越高。看懂曲線，往往比盲目重啟任務更有用。
還有一個很容易忽略的點，是看“恢復斜率”。如果你暫停了部分寫入，或者業務峰值過去後，延遲開始明顯下降，說明 DTS 還有追平的能力，只是當下吞吐不夠；如果你已經降載，延遲卻幾乎不動，那就要懷疑是目標庫被鎖住、索引過重，或者某個大事務卡住了整個回放鏈路。
三、源庫問題是最常見的根因
1. 大事務比高併發更可怕
很多人以為高併發才會拖慢同步，其實真正容易把 DTS 壓住的，常常是大事務。一次性更新大量行、超大批量刪除、長時間不提交的事務，會讓 binlog 在短時間內堆出很高的密度。DTS 可以讀，但回放要按事務邊界處理，這就很容易形成堆積。你在源庫上看到的是一條 SQL，DTS 看到的卻是一整串需要完整落地的變更。
大事務的危險還在於，它不只吃同步資源，還會拖長鎖持有時間，讓後續 SQL 也排隊。表面上延遲是 DTS 顯示出來的，實際上源庫自己已經先變慢了。處理這類情況，最有效的辦法不是硬扛，而是拆分事務、分批提交、避開高峰，讓 binlog 變得更平滑。
2. 批量更新和熱點表會放大問題
如果某張表是業務熱點，頻繁被更新同一批行，DTS 看到的不是平均負載，而是非常集中的寫入尖峰。這種場景下，即便總寫入量沒有那麼誇張，單表熱度也足以讓增量同步追不上。熱點表還有一個特徵：源庫的鎖衝突不明顯，但目標庫回放時會在索引和唯一性檢查上消耗大量時間，導致同步速率下降。
排查時可以重點看是不是某幾張表貢獻了大部分 binlog。很多任務的問題並不平均，而是被一兩張大表拖住。只要找出這幾個“主犯”，後面的處理方向就清楚了：要麼降頻，要麼拆表，要麼把同步窗口挪到更平穩的時段。
3. DDL 和結構變更別當成普通變更
DDL 往往比普通 DML 更容易造成停頓。因為結構變更不只是“插入一條記錄”那麼簡單，它可能涉及元數據鎖、表重建、索引重建，甚至會讓回放節點暫時等待。某些看起來很普通的改表操作，在業務高峰期做，對 DTS 來說就是一顆延遲炸彈。
如果同步任務正在追趕，源庫又連續發生 DDL，延遲通常不會像人想像中那樣“邊跑邊補”。更常見的是，DDL 造成一段明顯空窗，接著延遲被拉長。這時候不要急著懷疑網路，先確認是不是結構變更本身造成了同步排隊。
四、網路不是唯一原因，但經常是放大器
很多人排查延遲，第一反應是看網路。其實網路通常不是唯一根因，卻常常是把問題放大的那個環節。源庫和 DTS 節點之間如果跨地域、跨可用區，或者共用帶寬比較緊，當寫入量一上來，傳輸就很容易接近上限。這時候即便服務本身沒有故障，也會因為通道吞吐不足而表現成延遲累積。
不要只看延遲高不高，要看通道是不是穩。短時抖動、丟包、重傳、帶寬打滿，都會讓同步斜率變差。尤其是在多任務共用同一出口時，別的任務一忙，自己的增量同步也可能跟著掉速。這種情況下，單純重啟 DTS 沒有意義，因為根因在通道資源，不在任務本身。
如果排查發現源庫和目標庫都很空閒，DTS 卻總是跑不到預期速度，就要把重點放到傳輸路徑上。能同地域就盡量同地域，能避免多餘跳轉就避免，多任務共享資源的場景下，更要預留足夠的帶寬和穩定性。
五、目標庫慢，往往比源庫慢更隱蔽
增量同步追不上，很多人只會盯著源庫，卻忘了目標庫才是最終落點。目標庫如果 IOPS 不夠、CPU 飽和、磁碟寫入延遲高，或者長時間被查詢和維護任務佔住，DTS 回放速度就會被拖下來。尤其是帶很多二級索引的表，插入和更新一條數據，實際上要改多份索引結構，回放成本遠高於看起來的行數。
目標庫的鎖也是常見元兇。當有業務在查大表、跑報表、做批量維護時，DTS 在回放某些更新或刪除操作時，可能被鎖等待卡住。這種卡住不像報錯那樣顯眼，表現往往只是“速度突然變慢，然後延遲越積越大”。如果不看目標庫負載，很容易誤判成 DTS 自身問題。
騰訊雲實名認證 還有一類場景是目標庫表結構太重。索引多、約束多、觸發器多、外鍵關係複雜，這些都會讓回放成本成倍上升。同步時看的是“把數據寫進去”，實際上執行的是一連串檢查和維護。想讓增量同步追得上，先讓目標庫自己跑得動。
1. 先排查慢 SQL 和鎖等待
如果增量延遲持續居高不下，先看目標庫是不是有慢 SQL、死鎖、行鎖等待、元數據鎖等待。只要回放端被卡住，DTS 再快也推不動。這一步的判斷很直接：同樣的業務量下，目標庫的寫入耗時是不是明顯比平時更長，是否伴隨 CPU 飆高、磁碟寫入增大、Buffer 命中下降。這些信號一旦出現，就不要只在 DTS 端找答案。
2. 索引越多，不代表同步越穩
騰訊雲實名認證 很多團隊習慣給目標庫建很多索引，認為這樣查詢會更快。事實上，在同步壓力面前，索引過多常常是負擔。每一次插入、更新、刪除，都要同步維護所有相關索引。同步階段最怕的不是單條慢，而是成千上萬條一起慢。必要時可以評估是否先保留核心索引，將不急用的索引放到同步完成後再補建。
六、DTS 任務配置也會影響追平能力
有些延遲問題不是源庫不行，也不是目標庫不行，而是任務配置本身把自己限制住了。比如同步對象太多、單任務承擔的表範圍太大、某些特殊表沒有合理拆分，或者映射規則過於複雜，都會降低增量階段的實際吞吐。任務能不能追平，不只看服務開沒開，更看配置是不是適合這個業務。
如果一個任務裡既有超大表，又有大量小表，處理路徑往往很不均衡。大表拖住主線，小表堆在旁邊，看起來都在同步，實際上每一類表的阻塞點不同。這種時候，把同步對象重新分組，或者將高頻表和低頻表拆到不同任務，常常比單純擴容更有效。
還要注意衝突處理和 DDL 同步策略。有些配置看似穩妥，實際上在碰到異常數據、唯一鍵衝突、字段類型差異時，會讓任務進入反覆重試。延遲一旦被重試放大，追平就更難。配置不是越多越好，而是要和實際業務節奏匹配。
七、實際排查時，可以按這個順序走
第一步，先確認延遲是在什麼時候開始拉開的，是高峰期、批量任務、DDL 之後，還是某次目標庫變更之後。把時間點找準，範圍就縮小了一半。第二步，看源庫寫入量和 binlog 產生速度，有沒有大事務、批量更新、熱點表、長事務。第三步，看網路和 DTS 任務本身的吞吐，是否有明顯抖動。第四步，看目標庫是否存在鎖等待、慢 SQL、磁碟壓力、CPU 飽和或索引過重。第五步，再回頭看任務配置是否需要拆分、降載或調整同步窗口。
騰訊雲實名認證 如果你只做一件事，那就是判斷“問題在產生端，還是在消費端”。產生端太快，增量必然追不上；消費端太慢，延遲就算暫時沒爆，也只是遲早的事。真正高效的排查，不是把所有可能都試一遍，而是儘快找到短板在哪一端。
八、一個典型場景：不是 DTS 慢，而是目標庫撐不住
有些案例很有代表性。某次業務活動期間，源庫一張訂單明細表每分鐘都有大量更新，DTS 延遲從幾十秒一路升到幾十分鐘。最開始團隊以為是跨地域傳輸有問題，後來發現網路很穩，源庫也沒有異常，真正卡住的是目標庫。那邊同時在跑查詢報表，表上還有很多二級索引，回放一條更新都要耗費不小代價。
最後的處理很直接：先把部分查詢流量移走，降低目標庫壓力；再把非核心索引暫緩處理；同時把源庫的批量更新拆小，避免一次提交過大。幾輪調整後，延遲開始明顯回落，最終追平。這個案例說明，增量同步追不上時，別急著把責任全推給 DTS。很多時候，真正的問題是整個鏈路沒有為高峰預留足夠空間。
九、想避免再次發生，就要提前做容量和節奏管理
增量同步最怕臨時抱佛腳。正式上線前，應該先評估源庫峰值寫入能力、目標庫落地能力、同步鏈路帶寬和任務拆分方式。尤其是業務有大促、活動、結算、日終批處理這些明顯節點時，更要提前做壓力預估。不要等延遲飆上來才想辦法，因為那時候修正成本最高。
平時也要養成幾個習慣：大表批量操作盡量錯峰；DDL 先評估對同步的影響；目標庫索引不要一股腦堆滿；監控裡要同時看延遲、TPS、CPU、IOPS、鎖等待和網路吞吐。只盯著一個延遲數字，很容易誤判。真正穩定的同步，靠的不是偶爾救火，而是把每一段都留出餘量。
最後要記住，DTS 增量同步階段追不上，不一定代表系統壞了，但一定代表鏈路中某一環不夠快。先找源庫，再看傳輸，接著查目標庫，最後回到任務配置。只要順著這條線查，很多看似棘手的延遲問題，其實都能找到清楚的答案。
