Lag Control

PGDオリジンノード上のデータベースアプリケーションのデータスループットは、コミットされたデータがダウンストリームピアノードに安全にレプリケートできる速度を超える場合があります。この不均衡が高可用性アプリケーションで一定期間を超えてまたは慢性的に続く場合、ディザスターリカバリーまたはビジネス継続性計画に関連する組織の目標が満たされない可能性があります。

レプリケーションラグコントロール（RLC）機能は、動的レート制限デバイスを使用してこの不均衡を調整し、PGDグループノード間のデータフローがこれらの組織の目標に準拠するように設計されています。これは、PGDノード間のレプリケーションラグの程度を制御することによって行います。

これらの目的の一部には以下が含まれます。

  • 目標復旧時点（RPO）は、計画外のイベントが原因で失われる可能性のあるデータの最大耐量を指定し、通常は時間量として表されます。レプリケートされないシステムでは、RPOを使用してバックアップ間隔を設定し、コミットされたデータが障害によって失われるリスクを制限します。レプリケートされたシステムの場合、RPOは、1つ以上のピアノードに安全に適用されていないコミットされたデータの許容量を決定します。

  • リソース制約目標（RCO）は、有限のストレージ制約があることを認めています。このストレージには、データベースファイル、WAL、および操作を継続するために必要な一時ファイルまたは中間ファイルが含まれます。レプリケートされたシステムの場合、ラグが増加すると、これらのストレージリソースに対する要求も増加します。

  • グループ弾性目標（GEO）は、ノードがピアノードに受け入れられない形で保存できないクリップで新しいデータを発信していないことを保証します。その場合、その条件の検出は、データベースノードの数を拡張する決定における1つのメトリックとして使用できます。同様に、その状態が緩和すると、データベースノードの数を縮小する決定に影響を与える可能性があります。

ラグ制御は、クライアント接続がREAD WRITEトランザクションをコミットできる速度を制御することにより、レプリケーションの遅延を管理します。レプリケーションラグは、達成する目的に応じて、ラグタイムまたはラグサイズとして測定されます。トランザクションのコミット率は、構成されたPGDコミット遅延時間を使用して調整されます。

要件

ラグ制御の使用を開始するには：

  • すべてのデータベースアプリケーションが許容できる最大許容コミット遅延時間max_commit_delay を決定します。

  • 使用するラグメジャーを決定します。ラグサイズmax_lag_size またはラグタイムmax_lag_time のいずれかを選択します。

  • 関与するグループまたはサブグループ、および確認を満たすために必要な各コレクション内のノードの最小数を決定します。この情報は、コミットスコープルールの定義の基礎を形成します。

構成

コミットスコープでラグ制御を指定すると、コミットスコープルールが及ぶノード全体で一貫性のある調整されたパラメーター設定が可能になります。トップグループのデフォルトのコミットスコープ、またはオリジングループのコミットスコープの一部として、ラグ制御仕様を含めることができます。

この例では、 commitスコープへの移行 のサンプルノードグループを使用して、2つのデータセンターのラグ制御ルールを示します。

- - create a Lag Control commit scope with individual rules
- - for each sub-group
SELECT bdr.add_commit_scope(
    commit_scope_name := example_scope,
    origin_node_group := left_dc,
    rule := ALL (left_dc) LAG CONTROL (max_commit_delay=500ms, max_lag_time=30s) AND ANY 1 (right_dc) LAG CONTROL (max_commit_delay=500ms, max_lag_time=30s),
    wait_for_ready := true
);
SELECT bdr.add_commit_scope(
    commit_scope_name := example_scope,
    origin_node_group := right_dc,
    rule := ANY 1 (left_dc) LAG CONTROL (max_commit_delay=0.250ms, max_lag_size=100MB) AND ALL (right_dc) LAG CONTROL (max_commit_delay=0.250ms, max_lag_size=100MB),
    wait_for_ready := true
);

パラメーター値は、GUCパラメーター規則と互換性のあるユニット仕様を許可します。

グループコミットとCAMOルールの仕様も含む既存のコミットスコープルールに、ラグ制御コミットスコープルールを追加できます。

max_commit_delay パラメーターは、必要に応じて、サブミリ秒の設定を含む、小数部を含むミリ秒の指定を許可および推奨します。

概要

ラグ制御は、クライアント接続レベルで動作する動的TPSのレート制限メカニズムです。構成されたラグコントロールの制約を満たしながら、できるだけ目立たないように設計されています。これは、十分なPGDノードが構成されたラグメジャーしきい値を下回るのに十分な速度で変更をレプリケートできる場合、PGDランタイムのコミット遅延は0ミリ秒に固定されたままであることを意味します。

そうでない場合は、PGDランタイムのコミット遅延を必要に応じて最小限に調整しますが、適合ノードの数が最小しきい値に戻るまで、それ以上には調整しません。

最小ノードしきい値に達した後でも、ラグ制御は、PGDランタイムのコミット遅延をゼロに戻そうとし続けます。 PGDコミット遅延は、ほとんどの場合、平衡レベル付近で上下する可能性がありますが、データスループットまたはラグ適用率が向上すると、コミット遅延は時間の経過とともに減少します。

PGDコミット遅延は、コミット後の遅延です。これは、トランザクションがコミットされた後、トランザクションによってロックまたは取得されたすべてのPostgresリソースが解放された後に発生します。したがって、遅延は、同時アクティブなトランザクションによる値の監視または変更、またはリソースの取得を妨げることはありません。 Postgres拡張機能で管理される外部リソースについては、同じ保証はできません。拡張機能の依存関係に関係なく、PGD拡張機能がpostgresql.conf の拡張機能ベースのリソースマネージャーの前にリストされている場合、同じ保証を行うことができます。

厳密に言えば、PGDコミット遅延はトランザクションごとの遅延ではありません。これは、特定のクライアント接続のトランザクションのストリームでのコミット遅延の平均値です。この手法により、コミット遅延と値のきめ細かな調整により、OSスケジューラの粗い粒度、クロック割り込み、およびシステム負荷による変動を回避できます。また、PGDランタイムのコミット遅延を可能な限り最小の期間のマイクロ秒以内に解決して、ラグメジャーのしきい値を維持することもできます。

注釈

PGDのコミット遅延とPostgresのコミット遅延を混同しないでください。それらは無関係であり、異なる機能を実行します。一方を他方で置き換えないでください。 !!!

取引申請

PGDコミット遅延は、ユーザーアプリケーションのデータを変更するすべてのREAD WRITEトランザクションに適用されます。この動作は、宣言されたREAD WRITEトランザクションを含む、データを変更しないトランザクションはコミット遅延から免除されることを意味します。

非同期トランザクションのコミットは、PGDコミット遅延も実行します。これは直感に反するように見えるかもしれませんが、非同期コミットは、そのパフォーマンスのおかげで、レプリケーションラグの最大の原因の1つになる可能性があります。

PostgresおよびPGD補助プロセスは、トランザクションのコミットで遅延しません。最も注目すべきことに、PGDライターは、ローカルノードでリモートトランザクションを適用するときにコミット遅延を実行しません。 PGDライターは送信レプリケーションラグに何も寄与せず、トランザクションコミットが遅延によって調整されないことにより、受信レプリケーションラグを最も削減できるため、これは設計によるものです。

制限事項

最大コミット遅延は、ハード制限を表す上限値であり、コミット遅延が設定値を超えることはありません。逆に、最大ラグはサイズと時間の両方で測定され、超えることができるソフト制限です。最大コミット遅延に達した場合、継続的な増加を防ぐための遅延対策に追加のバックプレッシャーはありません。

PGDレプリケーションセットを変更しないオリジントランザクションをコミット遅延から免除する方法はありません。これらのトランザクションでは、最大トランザクション遅延を0にSET LOCALすると便利です。

注意事項

アプリケーションTPSは、レプリケーションラグに影響を与える可能性のある多くの要因の1つです。その他の要因には、PGDコミット遅延の効果が低下する可能性のあるトランザクションの平均サイズが含まれます。特に、バルクロード操作はレプリケーションラグの上昇を引き起こす可能性があります。

同様に、非常に高いOLTP要件と適度なデータ変更を伴うアプリケーションは、許容可能なPGDコミット遅延設定によって不当に制限される可能性があります。

このような場合、 SET [SESSION|LOCAL] コマンドを使用して、これらのアプリケーションのラグ制御設定をカスタム構成したり、それらのアプリケーションを変更したりすると便利です。たとえば、バルクロード操作は、トランザクションスナップショットの期間とWAL保持サイズを制限したり、バルクロードが失敗した場合のリスタートポイントを確立したりするために、複数の小さなトランザクションに分割される場合があります。ラグ制御に従い、これらのトランザクションコミットは、非常に長いPGDコミット遅延をスケジュールして、以前の部分的なバルクロードによって寄与されたラグを消化できるようにすることもできます。

組織目標の達成

前述の目標リストの例では：

  • RPOは、適切な最大ラグタイムを設定することで満たすことができます。

  • RCOは、適切な最大ラグサイズを設定することで満たすことができます。

  • GEOは、PGDランタイムコミット遅延とPGDランタイムラグメジャーを監視することによって満たすことができます。

前述のように、最大PGDランタイムコミット遅延がPGDで構成されたコミット遅延制限に固定され、ラグメジャーが一貫してPGDで構成された最大レベルを超える場合、このシナリオはPGDグループ拡張のマーカーになります。