操作及監控資料流

GoldenGate 端監控

• 確認「資料串流」資源存在且可在「分送服務」中使用。

• 監控傳送的記錄和位元組、作業計數、DDL 計數、表格活動，以及 UI 或服務測量結果公開的網路統計資料。

• 複查「分送服務」日誌以進行認證、歷程檔查詢、位置查詢、綱要產生、大小截斷以及 WebSocket 中斷連線錯誤。

• 獨立監督來源 Extract 和歷程檔產生。狀況良好的 WebSocket 無法傳遞未到達歷程檔的資料。

消費者度量

公制	為何重要
連線狀態和重新連線計數	偵測網路、認證、代理主機和服務不穩定。
上次接收與上次確認時間 pos	將資料送達與成功的持久處理分開。如果位置被視為敏感，則記錄雜湊或受保護的值。
依類型 / 表格區分的記錄和位元組	識別未預期的磁碟區、篩選錯誤以及偏差。
處理延遲	從 op_ts 到長期下游確認的時間。來源與消費者時鐘差異的科目。
內部佇列深度和最舊的佇列時效	在記憶體耗盡之前偵測背壓。
綱要 / 描述資料版本變更	偵測 DDL 與合約變更。
重複與冪等衝突計數	驗證遞送與檢查點行為。
無法寄出的信件與驗證失敗	顯示需要手動或自動修正的記錄。

緩衝與容量規劃

bufferSize 控制服務將其記憶體內訊息佇列排清至從屬端的位元組臨界值。較大的值可以提升批次處理效率，但可以增加每個訊息的記憶體使用量和延遲。較小的值可以減少延遲，但會增加訊息負荷。它不是持久的佇列，不會取代歷程檔保留，也不會移除對消費者背壓控制的需求。

• 使用代表性交易大小、LOB、DDL、表格計數以及尖峰傳輸量進行測試。

• 設定高於最大預期批次的 WebSocket 與代理最大訊息大小。

• 使用有界佇列並快速失敗，而不是允許無界限的記憶體成長。

• 分別接收網路、驗證、下游 I/O 以及檢查點確認，以便測量每個階段。

重新連線策略

• 從最後一個持久性檢查點重新連線，而不是最後一次收到的記錄。

• 使用指數偏移，最大延遲和抖動。

• 穩定連線之後重設延遲。

• 將無法重試的失敗項目分類，例如證明資料無效或無法使用的已儲存位置，並發出操作員警示，而非永久重試。

• 在復原期間保留相同的輸出合約。如果串流組態已變更，請先完成相容性驗證後再繼續。

多位用戶

「資料串流」未提供 Kafka 式用戶群組，或伺服器管理的每個用戶偏移量。每個獨立用戶端都必須維護自己的檢查點，並根據其連線和 begin 值接收記錄。除非外部協調器保證單一擁有權和已排序的檢查點更新，否則請勿在並行作用中用戶之間共用一個檢查點。

更改管理

• 啟動資料流組態的版本，並使用用戶版本產生 AsyncAPI YAML。

• 測試建立、連線、穩定狀態處理、中斷連線、重新啟動、保留位置失敗、DDL、大型記錄以及證明資料輪換。

• 請先部署相容的用戶程式碼，再啟用新的有效負載欄位或綱要變更。

• 保留可保留最後已知良好檢查點與組態的倒回計畫。