檢查點、復原以及傳遞語意

瞭解檢查點、復原以及從資料串流組態傳遞。

pos 公開合約

每個非描述資料 DML 或 DDL 記錄預設都會包含不通透的 pos 記號。在內部，記號包含足夠的 GoldenGate 位置資訊來識別記錄，包括確認或順序資訊、交易識別以及記錄順序。它的編碼不是公用來源座標格式，會因來源類型和版本而有所不同。

執行	不要
成功處理後儲存精確字串。	剖析以取得 Oracle SCN、PostgreSQL LSN、MySQL 二進位日誌座標、SQL Server LSN 或任何其他來源特定偏移。
將其擴展到資料流、來源追蹤合約和消費者。	以詞彙或數字方式比較職位以決定順序。
在 URL 中當作 begin 時，進行百分比編碼。	去除、標準化、串接、解密或重寫。
使用個別的 csn、xid、opSeqno 及 transInd 欄位進行診斷或交易分析。	重複使用來自其他串流、其他篩選合約或其他環境的位置。

來源可攜性：Oracle、PostgreSQL、MySQL、SQL Server 及其他支援來源的用戶端復原演算法故意相同：保留不透明的 pos，然後讓它維持不變。「資料流」用戶端合約既不需要也不支援來源特定座標剖析。

檢查點必須代表其業務效果為持久的最後一個記錄。在商業寫入之前儲存可能會在當機後遺失資料。在個別交易中儲存非冪等寫入時，可能會在當機後產生重複項目。

端對端正好模式

樣式	運作方式	於下列情況使用
單元接收與檢查點交易	在相同的資料庫交易中寫入商業記錄和新的 pos。	接收器與檢查點可以共用交易資料存放區。
冪等索引鍵	使用 pos 或業務索引鍵加上作業識別作為唯一索引鍵；重試相同記錄會變成 no-op。	接收器支援唯一性或條件性寫入。
長期暫存日誌	將記錄和 pos 原子附加至持續記錄，然後獨立處理記錄。	業務處理速度緩慢、多步驟或跨系統。
調節至少一次	定期接受重複項目、重複項目，以及調節盤點或總和檢驗。	使用案例可容許最終更正。

附註： Data Stream exactlyOnce 說明服務端重複的隱藏與復原回應。由於 WebSocket 通訊協定沒有與用戶端進行任何記錄的交易認可，因此它不會完全產生任意下游副作用。

服務品質

請參閱下表的「服務品質」準則：

模式	重複	無法取得已儲存的職位	建議使用
exactlyOnce	抑制在復原和來源歷程檔重新啟動 / 放棄處理期間辨識的重複項目。	連線因發生錯誤而失敗。	長期業務處理的預設值。與單元或冪等用戶邏輯配對。
atLeastOnce	在復原和來源歷程檔重新啟動 /abend 處理期間不會抑制重複項目。	連線因發生錯誤而失敗。	在偏好重新執行且使用者設計為去除重複時使用。
atMostOnce	隱藏已辨識的重複項目。	服務會尋找下一個可用的記錄並繼續，這可能會略過資料。	只有在資料遺失明確可接受，且向前進度比完整性更重要時才可使用。

交易中繼資料與排序

請參考下表，瞭解交易中繼資料與排序需求：

欄位	目的	限制
xid	將與來源交易相關聯的記錄分組。	格式與來源相依，應視為字串。
csn	設定時顯示來源確認序號。	意義與格式是來源相依的；請勿用作重新啟動記號。
opSeqno	記錄異動內的序號。	啟用並選擇性地將其明確重新命名。
transInd	B first、M middle、E last 或 W whole/single-operation transaction (單一作業交易)。	篩選可以移除記錄，並讓觀察順序不完整。協調處理也可以降低使用率。
pos	記錄的唯一復原位置。	不透明；不要從交易邊界的文字排序或導出交易邊界 。

請勿假設連線一律在交易界限開始。時間戳記查尋或保留軌跡邊界可在較早的作業無法再使用後開始。如果應用程式需要完整的來源異動，請設計異動緩衝區，定義大型異動的限制，並指定異動開始無法使用時應執行的動作。

當已儲存的職位無法使用時

若要檢查無法使用的已儲存職位，請檢查下列項目：

• 確認檢查點屬於相同的資料流、來源軌跡，以及篩選 / 輸出合約。

• 確認該值是以百分比編碼且未變更。

• 確認尚未永久清除包含此位置的歷程檔區段。

• 在 exactlyOnce 或 atLeastOnce 中，將錯誤視為復原未預期事件。回復歷程記錄、選擇已核准的時間戳記或最早位置，並在繼續前先調節下游狀態。

• 使用 atMostOnce，服務可以在下一個可用的記錄繼續。記錄產生的資料差距，並執行業務核准的調節程序。

歷程檔保留規劃

將歷程檔保留設為超過復原點目標加上作業偵測和回應時間。例如，可以離線 24 小時且事件回應需要 12 小時的用戶需要超過 36 小時的可用歷程檔，而大型積壓和維護則需要額外的利潤。bufferSize 不會延長歷程檔保留時間。