整庫即時同步任務涉及結構遷移、全量初始化、即時增量等多個階段，表數量多、運行周期長，營運複雜度高。本文介紹整庫即時同步任務的啟動停止、配置修改、警示設定等核心營運操作，提供排查方法和調優建議，協助高效管理整庫即時同步任務的生命週期。
前提條件
執行營運操作或排查問題前，確認滿足以下條件：
許可權要求
源端帳號：具備讀取庫、表、欄位、主鍵和索引等中繼資料的許可權，以及讀取源端變更日誌的許可權（如 Binlog、WAL、Oplog）。
目標端帳號：具備建表、改表和寫入許可權。
網路連通性
資源群組到源端和目標端需保持網路連通。網路異常會導致結構遷移失敗、全量初始化卡住或即時增量中斷。
源端日誌保留
源端變更日誌（changelog）的保留時間需覆蓋任務可能停止的視窗，以及全量初始化期間的增量資料積累量。日誌保留不足是導致任務停止後無法從原位點恢複的最常見原因。
資料來源和通道相容性
不同資料來源支援的同步能力（全量、增量、DDL 等）各不相同，以頁面可配置範圍為準。確認源端和目標端的版本在通道支援範圍內。
適用通道和邊界
在排查整庫即時同步任務問題之前，先按任務形態、通道能力和排查重點進行判斷，確認本文適用於當前情境。
判斷項 | 適用口徑 | 不適用 / 重點看 |
任務形態 | 多表或整庫範圍 CDC 即時同步。 | 本文檔不適用與單表即時同步情境，單表即時同步排查方式見：單表即時同步營運與調優。 |
典型通道 | 資料庫源 → Hologres / MaxCompute / ADB / Doris / StarRocks / SelectDB / Kafka / DLF / Lindorm / Elasticsearch / OSS | 非此類通道不適用。 |
排查重點 | 日誌保留、位點、主鍵、DDL、源庫負載、目標端寫入、分區、提交、小檔案、限流、堆積。 | 除任務狀態外，還需結合指標和日誌進行細粒度排查。 |
整庫即時同步依賴源端持續提供 Binlog、WAL、Oplog 或等價變更日誌，目標端需支援當前寫入模式、主鍵/唯一鍵語義和必要的結構變更。不滿足這兩個條件時，任務可能無法正常運行或無法保證資料一致性。
任務階段
整庫即時同步任務通常包含以下階段，每個階段的營運重點不同。
階段 | 說明 | 營運重點 |
結構遷移 | 從源端讀取庫表和欄位資訊，在目標端建立或更新表結構 | 源端中繼資料許可權、目標端建表許可權、欄位類型映射、表名映射規則 |
全量初始化 | 讀取源端歷史資料並寫入目標端，用於補齊任務啟動前已存在的資料 | 切分鍵、全量並發、源端串連數、資源群組、目標端寫入能力、全量和增量追平 |
即時增量 | 持續消費源端變更並寫入目標端 | 位點延遲、讀寫吞吐、Failover、Checkpoint、DDL 事件、源端日誌保留 |
整庫即時任務通常先完成結構遷移和全量初始化，再持續處理即時增量。
全量初始化期間產生的增量資料需要依賴源端日誌保留和即時鏈路追平，因此啟動、停止、重跑和加表時都要同時關注全量進度和即時延遲。
營運操作
啟動和停止
啟動任務後，按以下順序確認任務進入正常運行狀態：
確認結構遷移是否完成，目標端表結構已建立。
觀察全量初始化是否正常讀取和寫入，全量讀取速率和寫入速率穩定，已完成表數持續增長。
確認即時增量進入正常運行狀態，即時延遲在合理範圍內，無頻繁 Failover，Checkpoint 正常提交。
停止任務前，需要確認源端日誌保留時間是否足夠覆蓋停止視窗。任務停止過久後，源端 Binlog、WAL 或訊息日誌被清理，可能無法從原位點繼續恢複。恢複任務時，任務會從上次儲存的位點繼續；如果位點已到期，需評估重設位點或重新初始化的風險（詳見「常見問題 > 任務停止後無法從原位點恢複」）。
修改配置
運行中的整庫即時任務可能需要新增表、刪除表、調整表映射、調整全量或即時資源。修改配置後，應按頁面提示提交並應用程式更新。
變更類型 | 風險點 | 建議 |
新增表 | 需要重新讀取中繼資料，並按通道能力執行結構遷移、全量初始化和即時增量接入 | 先確認新增表匹配選擇規則，再重新整理表映射；關注新表全量進度、即時接入狀態和源端日誌保留 |
刪除表 | 運行中減表可能影響已有表映射、目標端資料和下遊依賴 | 刪除前確認業務不再依賴該表；異常情境下優先建立任務承接新範圍 |
修改映射規則 | 可能導致目標表名衝突、欄位缺失、分區變化或已有資料處理策略變化 | 提交前檢查目標表名、欄位類型、主鍵、分區、附加欄位和目標端已有資料 |
調整資源 | 全量初始化和即時增量使用的資源、並發和串連數可能不同，調整不當會增加源端或目標端壓力 | 逐步調整，每次調整後觀察全量速率、即時延遲、Failover、Checkpoint 和資源使用率 |
配置生效說明：
表映射重新整理和新增表接入通常支援熱更新，不需要暫停任務。
資源規格（如 CU）調整可能需要重啟任務或等待下一個 Checkpoint 生效，具體以頁面提示為準。
修改映射規則建議在任務暫停後執行，避免對運行中的資料產生影響。
配置變更失敗時，回退到變更前配置並重新提交。
警示配置
整庫即時任務建議至少關注以下警示類型（部分）：
警示類型 | 適用情境 | 說明 |
任務狀態異常 | 所有任務 | 任務失敗或異常退出時立即警示 |
業務延遲 | 所有任務 | 即時延遲超過業務可接受閾值時警示 |
Failover | 所有任務 | 頻繁 Failover 通常意味著需要介入處理 |
資源使用率 | 資源緊張情境 | CPU、記憶體或網路利用率過高時警示 |
DDL 通知 | 涉及 DDL 的通道 | DDL 事件可能影響目標端結構，建議及時關注 |
訊息堆積 | Kafka / DataHub / LogHub 源 | 結合源端控制台或任務指標觀察分區、Shard 或 Topic 的積壓 |
MySQL、PostgreSQL 等日誌型源端還需要關注 Binlog、WAL 等日誌保留時間，避免日誌到期導致任務無法恢複。
警示規則配置的詳細步驟，參見公用警示規則。
排查方法
結構遷移失敗
結構遷移失敗通常和許可權、中繼資料讀取、欄位類型或目標端建表有關。排查順序如下：
檢查源端帳號是否能讀取庫、表、欄位、主鍵和索引等中繼資料。
檢查任務使用的資源群組到源端和目標端是否連通。
檢查目標端帳號是否具備建表、改表和寫入許可權。
檢查表名、庫名或 Schema 映射是否產生重複名稱或非法名稱。
檢查欄位類型、主鍵、分區欄位和附加欄位是否相容目標端。
正則選表或批量選表情境下，建議先用少量表驗證，再擴大同步範圍。
全量初始化慢或失敗
全量初始化慢或失敗時，先確認任務是否卡在資源初始化、讀取源端、寫入目標端，還是等待增量追平。排查時可以查看全量讀取速率、寫入速率、已完成表數、剩餘分區數、源端串連數和目標端寫入耗時。
現象 | 可能原因 | 處理建議 |
全量任務長時間未開始 | 資源群組排隊、資源初始化失敗、源端或目標端連通性異常 | 檢查資源群組狀態和網路連通性，確認源端、目標端帳號許可權正常 |
全量讀取速度低 | 切分鍵不均勻、源端 SQL 未走索引、源端負載高、串連數或 Quota 不足 | 檢查切分鍵和索引，適度調整全量並發；源端壓力高時先限速或錯峰運行 |
全量寫入速度低 | 目標端寫入能力不足、分區設計不合理、批量寫入參數不合適 | 檢查目標端負載、寫入 QPS、批量提交耗時和分區數量 |
全量完成後增量追平慢 | 全量期間源端變更量較大，即時鏈路需要回放積壓日誌 | 觀察即時延遲是否持續下降，同時確認源端日誌保留時間足夠 |
即時延遲升高
即時延遲升高時，先判斷任務是否仍在全量初始化追平階段，再區分瓶頸在讀端、鏈路處理還是寫端。
現象 | 可能原因 | 處理建議 |
全量完成後延遲仍較高 | 全量期間積累的增量較多、源端日誌讀取慢、目標端寫入追平慢 | 觀察增量讀取速率、寫入速率和源端日誌保留時間，確認延遲是否持續下降 |
讀端等待時間高 | 源端變更量突增、大事務、源端日誌積壓、分區或 Shard 傾斜 | 檢查源端寫入峰值、日誌增長、分區或 Shard 分布 |
寫端等待時間高 | 目標端寫入慢、限流、串連數不足、動態分區過多 | 檢查目標端資源、寫入 QPS、批量提交耗時和分區設計 |
頻繁 Failover | 記憶體不足、外部服務抖動、Checkpoint 失敗、DDL 處理異常 | 查看 Failover 前後日誌，結合記憶體、資源使用率和 Checkpoint 指標處理 |
DDL 事件後延遲升高 | DDL 處理耗時或目標端結構變更失敗 | 查看 DDL 事件和目標端許可權，確認 DDL 策略符合預期 |
如果源端為 Kafka、DataHub 或 LogHub，單個分區或 Shard 通常只能有一個並發消費。資料集中在少數分區時，增加任務總並發不一定有效。
新增表未同步
新增表未進入同步鏈路時，按以下順序確認：
新增表是否匹配當前庫表選擇規則。
表映射是否重新整理成功。
目標端是否完成建表或結構遷移。
任務是否支援運行時動態加表。
運行詳情中是否出現對應表的結構遷移、全量初始化或即時事件。
不支援動態加表的通道，需要修改配置並重新發布，或建立任務承接新增表。新增表需要歷史資料時，應確認該通道是否會為新增表執行全量初始化；不支援時再使用補資料或單獨全量同步能力。
調優建議
調優項 | 適用情境 | 建議 |
全量資源規格 / CU | 全量初始化排隊、運行速度低、資源群組利用率較高 | 逐步增加全量資源或錯峰運行，觀察全量讀取速率、寫入速率和源端負載 |
全量並發和切分鍵 | 全量階段運行有速度但整體較慢 | 選擇分布均勻且有索引的切分鍵，適度提高並發；源端壓力高時降低並發或限速 |
源端串連數 / Quota | 全量初始化報串連數、Quota 或限流相關錯誤 | 降低同源任務並發，或在源端能力允許時提高串連數和 Quota |
即時資源規格 / CU | CPU、記憶體、網路或資源群組利用率較高 | 逐步增加資源，觀察延遲、Failover 和 Checkpoint 是否改善 |
即時並發 | 多表、多分區或多 Shard 有足夠並行度 | 先確認不存在單表熱點或單 Shard 瓶頸，再增加並發 |
Checkpoint / Flush 間隔 | 寫端頻繁提交、批量提交開銷高 | 小幅調大後觀察吞吐和資料可見延遲，不建議一次調大過多 |
目標端批量寫入參數 | 寫端等待時間高 | 結合目標端產品限制調整 batch、flush、commit 或串連池參數 |
動態分區粒度 | 目標端分區過多或 Flush 壓力高 | 優先調整分區粒度，避免用秒級時間、訂單號、使用者識別碼 等高基數欄位做分區 |
全量初始化和即時增量的調優目標不同，全量側重點是穩定完成歷史資料寫入，即時側重點是持續追平增量延遲。調優後至少觀察一個穩定視窗，只看重啟後的短時間吞吐容易誤判效果。
資源設定大小的推薦值，參見Data Integration推薦 CU，實際使用時需根據實際情況調整。
常見問題
以下問題來自整庫即時同步任務的歷史排查沉澱，按任務階段分類。排查時先確認任務所處階段，再結合任務事件、作業記錄、指標、源端日誌保留和目標端結果交叉驗證。
結構遷移相關
問題 | 排查重點 | 處理建議 |
表映射重新整理慢、逾時或表不可選 | 資源群組連通性、源端中繼資料許可權、庫表數量、欄位數量、源端物件類型和資料來源緩衝 | 先縮小庫表範圍驗證；確認帳號具備讀取庫表、欄位、主鍵和索引許可權；對象不可選時以當前通道支援範圍為準 |
全量初始化相關
問題 | 排查重點 | 處理建議 |
全量初始化卡住或遲遲不開始 | 資源群組排隊、源端或目標端連通性、資料來源 Quota、全量階段資源、目標端建表結果 | 先確認結構遷移是否完成，再看全量子任務是否啟動；如果是 Quota 或串連數不足，優先降低並發或提升資料來源/目標端配額 |
即時增量相關
問題 | 排查重點 | 處理建議 |
全量完成後即時延遲仍然很高 | 全量期間積累的增量、源端日誌讀取速度、目標端寫入速度、Checkpoint 和 Failover | 觀察延遲是否持續下降；如果不下降，再分別檢查讀端位點、寫端等待、Checkpoint 失敗和目標端限流 |
任務停止後無法從原位點恢複 | Binlog、WAL、訊息日誌或消費位點是否已過保留時間；源端是否重建執行個體或清理日誌 | 停止任務前確認日誌保留時間能覆蓋停機視窗；位點不可用時通常需要重設位點或重新初始化，執行前評估重複和丟失風險 |
DDL 後任務失敗或延遲升高 | 當前源端可產生哪些 DDL、目標端支援哪些 DDL 處理動作、任務 DDL 策略和許可權 | 查看 DDL 事件和目標端結構變更結果；不支援的 DDL 不建議直接忽略，應先確認目標端結構和資料一致性影響 |
Delete 或 Update 後目標端資料不符合預期 | 目標端是否有可用於定位記錄的主鍵或唯一鍵；主鍵映射是否一致；寫入模式是否支援更新和刪除 | 優先檢查源端主鍵、目標端主鍵、表映射和髒資料日誌；目標端無有效主鍵或映射不一致時，更新和刪除可能無法正確落到目標記錄 |
訊息源相關
問題 | 排查重點 | 處理建議 |
Kafka、DataHub、LogHub 等訊息源延遲高 | 分區、Shard 或 Topic 是否有熱點；消費並發是否超過可並行消費的分區數；消費位點是否已落後過多 | 先看是否存在單分區或單 Shard 瓶頸；熱點集中時，單純增加總並發不一定有效，需要調整源端分區或目標端寫入能力 |
目標端寫入相關
問題 | 排查重點 | 處理建議 |
寫入 MaxCompute 等目標端時分區過多導致慢 | 動態分區欄位粒度、單個 Checkpoint 內分區數量、Tunnel/提交耗時、目標端限流 | 優先降低分區粒度或減少高基數欄位做分區；再結合目標端能力調整批量提交、分區緩衝和資源規格 |
資料一致性相關
問題 | 排查重點 | 處理建議 |
新增表後沒有同步歷史資料 | 新增表是否匹配選擇規則；表映射是否重新整理成功；通道是否支援為新增表執行全量初始化；新增表是否只接入即時增量 | 需要歷史資料時，確認新增表已開啟或觸發全量初始化；不支援時使用補資料或單獨全量同步能力補齊歷史資料 |
運行中刪除表或源端刪表後資料不一致 | 刪除表是否仍被任務規則匹配；DDL 策略如何處理 DROP TABLE；目標端是否已有下遊依賴 | 運行中減表前先確認業務不再依賴該表；源端刪表不等同於目標端自動清理，必要時在目標端按資料治理要求單獨處理 |
髒資料量異常 | 是否配置了容忍髒資料；欄位類型、長度、主鍵、非空約束、目標端寫入限制是否變化 | 不建議僅通過放大髒資料閾值讓任務繼續運行；先確認髒資料是否會導致目標端缺數或欄位異常，再決定修複資料、調整映射或臨時容忍 |
PostgreSQL 專項
問題 | 排查重點 | 處理建議 |
PostgreSQL 源端 WAL 堆積 | 複製槽 lag、消費位點、Checkpoint 和任務是否正常提交位點 | 如果任務消費正常但 WAL 不下降，需要檢查複製槽 lag 和位點提交情況，避免源端磁碟被 WAL 持續佔用 |
高風險操作檢查清單
執行減表、大批量加表、重啟任務、重跑全量初始化或大幅調參前，逐項確認以下內容。檢查不滿足時按對應建議處理後再執行操作。
當前源端日誌保留時間是否足夠，是否能覆蓋全量初始化和增量追平所需時間。
目標端是否已有資料或下遊依賴，重跑全量初始化前是否明確覆蓋、追加或清理策略。
新增表是否需要歷史資料，以及當前通道是否支援為新增表執行全量初始化。
是否存在未處理 DDL 或頻繁 Failover。
警示是否覆蓋任務狀態、全量初始化異常、業務延遲、Failover 和 DDL。