データ・ストリームの操作および監視

GoldenGate側の監視

• データ・ストリーム・リソースが存在し、分散サービスで使用可能であることを確認します。

• 送信されたレコードとバイト数、操作数、DDL数、表アクティビティー、およびUIまたはサービスメトリックによって公開されるネットワーク統計をモニターします。

• 配布サービスのログで、認証、証跡参照、位置参照、スキーマ生成、サイズ切捨ておよびWebSocket切断エラーを確認します。

• ソースExtractおよび証跡生成を個別にモニターします。正常なWebSocketは、証跡に到達していないデータを配信できません。

コンシューマ・メトリック

メトリック	重要な理由
接続状態および再接続数	ネットワーク、認証、プロキシ、サービスの不安定性を検出します。
最終受信および最終コミットpos	データ到着と永続処理を分離します。位置が機密とみなされる場合、ハッシュ値または保護された値を記録します。
タイプ/テーブル別のレコードおよびバイト数	予期しないボリューム、フィルタリング・エラーおよびスキューを識別します。
処理レイテンシ	op_tsから永続ダウンストリーム・コミットまでの時間。ソース・クロックとコンシューマ・クロックの差異の勘定科目です。
内部キューの深さおよび最も古いキューの経過時間	メモリ不足前のバックプレッシャーを検出します。
スキーマ/メタデータのバージョン変更	DDLおよび契約の変更を検出します。
重複および冪等性の競合数	配信およびチェックポイントの動作を検証します。
デッドレターおよび検証の失敗	手動または自動修正が必要なレコードを表示します。

バッファと容量の計画

bufferSizeは、サービスがインメモリー・メッセージ・キューをクライアントにフラッシュするバイトしきい値を制御します。値を大きくすると、バッチ処理の効率が向上しますが、メッセージごとのメモリー使用量および待機時間が増加する可能性があります。値を小さくすると、待機時間が短縮されますが、メッセージのオーバーヘッドが増加します。永続キューではなく、証跡の保持を置き換えず、コンシューマ・バックプレッシャー制御の必要性を排除しません。

• 代表的なトランザクション・サイズ、LOB、DDL、表数およびピーク・スループットを使用してテストします。

• WebSocketおよびプロキシの最大メッセージ・サイズを、予想される最大バッチより大きく設定します。

• バインド・キューを使用し、バインドされていないメモリーの増加を許可するのではなく、高速で失敗します。

• 各ステージを測定できるように、ネットワーク受信、検証、ダウンストリームI/Oおよびチェックポイントのコミットを分離します。

再接続戦略

• 最後に受信したレコードではなく、最後の永続チェックポイントから再接続します。

• 最大遅延とジッタで指数関数的なバックオフを使用します。

• 安定した接続後に遅延をリセットします。

• 無効な資格証明や使用不可の保存済位置などの再試行不可能な障害を分類し、永久に再試行するかわりにオペレータ・アラートを生成します。

• 回復時に同じ出力契約を保持します。ストリーム構成が変更された場合は、再開する前に互換性の検証を完了してください。

複数のコンシューマ

データ・ストリームは、Kafka形式のコンシューマ・グループまたはサーバー管理のコンシューマごとのオフセットを提供しません。各独立したクライアントは、独自のチェックポイントを維持し、その接続およびbegin値に従ってレコードを受信する必要があります。外部コーディネータが単一の所有権および順序付けされたチェックポイント更新を保証しないかぎり、同時にアクティブなコンシューマ間で1つのチェックポイントを共有しないでください。

チェンジ・マネジメント

• データ・ストリーム構成をバージョニングし、コンシューマ・リリースでAsyncAPI YAMLを生成しました。

• 作成、接続、定常状態の処理、切断、再起動、保持位置の障害、DDL、大きいレコードおよび資格証明のローテーションをテストします。

• 新しいペイロード・フィールドまたはスキーマの変更を有効にする前に、互換性のあるコンシューマ・コードをデプロイします。

• 最後に正常なチェックポイントおよび構成を保持するロールバック計画を保持します。