チェックポイント、リカバリおよび配信セマンティクス
データ・ストリーム構成からのチェックポイント、リカバリおよび配信について学習します。
pos公開契約
メタデータ以外のDMLまたはDDLレコードには、デフォルトで不透明なposトークンが含まれます。内部的には、トークンは、コミットまたは順序情報、トランザクション・アイデンティティ、レコード順序付けなど、レコードを識別するために十分なGoldenGate位置情報を持ちます。このエンコーディングは、パブリック・ソース座標形式ではなく、ソース・タイプおよびリリースによって異なる場合があります。
| 実行 | しない |
|---|---|
| 処理が成功したら、正確な文字列を格納します。 | 解析して、Oracle SCN、PostgreSQL LSN、MySQL binlog座標、SQL Server LSNまたはその他のソース固有のオフセットを取得します。 |
| データ・ストリーム、ソース証跡契約およびコンシューマにスコープ指定します。 | 位置を字句または数値で比較して順序を決定します。 |
URLでbeginとして使用する場合は、パーセント・エンコードします。 |
トリミング、正規化、連結、復号化またはリライトを行います。 |
診断またはトランザクション分析には、個別のcsn、xid、opSeqnoおよびtransIndフィールドを使用します。 |
別のストリーム、別のフィルタ契約または別の環境からのポジションを再利用します。 |
ソースの移植性:クライアント・リカバリ・アルゴリズムは、Oracle、PostgreSQL、MySQL、SQL Serverおよびその他のサポートされているソースで意図的に同じです。不透明なposを保持し、変更せずに返します。ソース固有の座標解析は、データ・ストリーム・クライアント契約では必須でもサポートでもありません。
チェックポイントは、ビジネス効果が永続的である最後のレコードを表す必要があります。ビジネス書込みの前に保存すると、クラッシュ後にデータが失われる可能性があります。別のトランザクションでべき等でない書込みの後に保存すると、クラッシュ後に重複が発生する可能性があります。
エンドツーエンドの厳密1回パターン
| パターン | 機能 | 使用条件 |
|---|---|---|
| アトミック・シンクおよびチェックポイント・トランザクション | ビジネス・レコードと新しいposを同じデータベース・トランザクションに書き込みます。 |
シンクおよびチェックポイントは、トランザクション・データストアを共有できます。 |
| 冪等性キー | posまたはビジネス・キーと操作IDを一意キーとして使用し、同じレコードを再試行すると操作できなくなります。 |
シンクは、一意性または条件付き書込みをサポートします。 |
| 永続ステージング・ログ | レコードおよびposを永続ログにアトミックに追加し、ログを個別に処理します。 |
ビジネス処理は低速、複数ステップ、または複数のシステムにまたがります。 |
| 照合で少なくとも1回 | 重複の受け入れ、定期的な重複解除、カウントまたはチェックサムの調整を行います。 | ユース・ケースでは、最終的な修正が許容されます。 |
ノート:データ・ストリームexactlyOnceでは、サービス側の重複抑制およびリカバリ・レスポンスについて説明します。WebSocketプロトコルにはクライアントとのレコードごとのトランザクション確認応答がないため、任意のダウンストリームの副作用が1回だけ発生することはありません。
サービス品質
次の表のQuality of Serviceのガイドラインを参照してください。
| モード | 複製 | 保存されたポジションは使用できません | 推奨使用方法 |
|---|---|---|---|
exactlyOnce |
リカバリおよびソース証跡の再起動/異常終了処理中に認識された重複を抑制します。 | 接続がエラーで失敗します。 | 永続ビジネス処理のデフォルトです。atomicまたはidempotentコンシューマ・ロジックとペアリングします。 |
atLeastOnce |
リカバリ中およびソース証跡の再起動/異常終了処理中の重複を抑制しません。 | 接続がエラーで失敗します。 | リプレイが優先され、コンシューマが重複除外されるように設計されている場合に使用します。 |
atMostOnce |
認識された重複を抑制します。 | サービスは、次に使用可能なレコードを検出して続行し、データをスキップできます。 | データ損失が明示的に受け入れられ、完全性よりも前進の進捗が重要である場合にのみ使用します。 |
トランザクション・メタデータおよび順序付け
トランザクション・メタデータおよび順序付け要件については、次の表を参照してください。
| フィールド | 目的 | 制限事項 |
|---|---|---|
xid |
ソース取引に関連付けられたレコードをグループ化します。 | 形式はソースに依存し、文字列として扱われる必要があります。 |
csn |
構成時にソース・コミット順序番号を公開します。 | 意味と形式はソースに依存し、再起動トークンとして使用しないでください。 |
opSeqno |
トランザクション内のレコード順序番号。 | 明示的に有効にし、必要に応じて名前を変更します。 |
transInd |
最初にB、中間M、最後Eまたは全体/単一操作トランザクションW。 |
フィルタリングによってレコードが削除され、観察された順序が不完全になる場合があります。調整処理によって、有用性が低下することもあります。 |
pos |
レコードの一意のリカバリ位置。 | 不透明です。トランザクション境界をテキストからソートまたは導出しないでください。 |
接続が常にトランザクション境界から始まるとは想定しないでください。タイムスタンプ・ルックアップまたは保持トレイル境界は、以前の操作が使用できなくなった後に開始できます。アプリケーションで完全なソース・トランザクションが必要な場合は、トランザクション・バッファを設計し、大規模なトランザクションの制限を定義して、トランザクションの開始が使用できないときに何をするかを指定します。
保存したポジションが使用できない場合
保存したポジションが利用できなくなった場合、以下の点に注意してください。
-
チェックポイントが同じデータ・ストリーム、ソース証跡およびフィルタ/出力契約に属していることを確認します。
-
値を変更せずにパーセント・エンコードされたことを確認します。
-
ポジションを含む証跡セグメントがパージされていないことを確認します。
-
exactlyOnceまたはatLeastOnceでは、エラーをリカバリ・インシデントとして扱います。証跡履歴をリストアし、承認されたタイムスタンプまたは最初の位置を選択し、再開する前にダウンストリーム状態を調整します。 -
atMostOnceを使用すると、サービスは次に使用可能なレコードで続行できます。結果のデータ・ギャップを記録し、ビジネス承認済照合プロシージャを実行します。
トレイル保持計画
リカバリ・ポイント目標と操作検出およびレスポンス時間を超えるように証跡の保存を設定します。たとえば、24時間オフラインにでき、インシデント・レスポンスに12時間かかるコンシューマは、使用可能な証跡を36時間以上必要とし、バックログとメンテナンスの余裕が増えます。bufferSizeでは、証跡の保存は延長されません。