Lag Control =========== PGD起点ノード上のデータベースアプリケーションのデータスループットは、コミットされたデータを下流のピアノードに安全にレプリケートできる速度を超える場合があります。高可用性アプリケーションでこの差が一定の期間を超えてまたは慢性的に続く場合、ディザスターリカバリーまたは事業継続計画に関連する組織の目標は満たされない可能性があります。 レプリケーションラグ制御RLC機能は、PGDグループノード間のデータフローがこれらの組織の目標に準拠するように、動的レート制限デバイスを使用してこの不均衡を調整するように設計されています。これは、PGDノード間のレプリケーションラグの程度を制御することにより行われます。 これらの目的の一部には次のものが含まれます。 - 目標復旧ポイントRPOは、計画外のイベントによって失われる可能性のあるデータの最大許容量を指定します。通常は時間として表されます。非レプリケートシステムでは、RPOを使用してバックアップ間隔を設定し、障害によるコミットされたデータの損失のリスクを制限します。レプリケートシステムの場合、RPOは、1つ以上のピアノードに安全に適用されていないコミットされたデータの許容量を決定します。 - リソース制約目標RCOは、有限のストレージ制約があることを確認します。このストレージには、データベースファイル、WAL、およびオペレーションの継続に必要な一時または中間ファイルが含まれます。レプリケートシステムの場合、遅延が増加すると、これらのストレージリソースへの要求も増加します。 - グループ弾性目標GEOは、ノードがピアノードに受け入れられないクリップで新しいデータを生成していないことを保証します。その場合、その条件の検出は、データベースノードの数を拡張する決定における1つのメトリックとして使用できます。同様に、その状態が和らぐと、データベースノードの数を契約する決定に影響を与える可能性があります。 Lag Controlは、クライアント接続がREAD WRITEトランザクションをコミットできるレートを制御することにより、レプリケーションラグを管理します。レプリケーションラグは、満たす目的に応じて、ラグタイムまたはラグサイズとして測定されます。トランザクションのコミットレートは、設定されたPGDコミット遅延時間を使用して調整されます。 要件 ---- Lag Controlの使用を開始するには - すべてのデータベースアプリケーションが許容できる最大許容コミット遅延時間\ ``max_commit_delay`` を決定します。 - 使用する遅延測定を決定します。ラグサイズ\ ``max_lag_size`` またはラグタイム\ ``max_lag_time`` のいずれかを選択します。 - 関係するグループまたはサブグループ、および確認を満たすために必要な各コレクションのノードの最小数を決定します。この情報は、コミットスコープルールの定義の基礎を形成します。 構成 ---- コミットスコープでラグ制御を指定すると、コミットスコープルールがスパンするノード全体で一貫した調整されたパラメーター設定が可能になります。ラグ制御仕様は、トップグループのデフォルトのコミットスコープに、またはオリジングループのコミットスコープの一部として含めることができます。 :ref:`コミットスコープ <コミットスコープ>` のサンプルノードグループを使用して、この例は、2つのデータセンターのラグ制御ルールを示します。 .. code:: sql - - 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`` パラメーターは、必要に応じてサブミリ秒設定を含む、小数部分を含むミリ秒の仕様を許可および推奨します。 概要 ---- Lag Controlは、クライアント接続レベルで動作する動的なTPSレート制限メカニズムです。構成された遅延制御のコンストレインを満たしながら、できるだけ目立たないように設計されています。これは、十分なPGDノードが構成された遅延測定しきい値を下回るように十分な速度で変更をレプリケートできる場合、 PGDランタイムコミット遅延が0ミリ秒に固定されることを意味します。 これに当てはまらない場合は、適合ノードの数が最小しきい値に戻るまで、PGDランタイムコミット遅延を必要に応じて最小限に調整しますが、それ以上にはなりません。 最小ノードしきい値に到達した後でも、Lag ControlはPGDランタイムコミット遅延をゼロに戻そうとし続けます。 PGDコミット遅延は、ほとんどの場合、平衡レベルを中心に上下する可能性がありますが、データスループットまたはラグ適用レートが向上すると、コミット遅延は時間の経過とともに減少します。 PGDコミット遅延は、コミット後の遅延です。これは、トランザクションがコミットされた後、トランザクションによってロックまたは取得されたすべてのPostgresリソースが解放された後に発生します。したがって、遅延は、同時アクティブなトランザクションがその値を監視または変更する、またはそのリソースを取得することを妨げるものではありません。 Postgres拡張機能によって管理される外部リソースについては、同じ保証はできません。拡張機能の依存関係に関係なく、PGD拡張機能が\ ``postgresql.conf`` の拡張機能ベースのリソースマネージャーの前にリストされている場合、同じ保証を行うことができます。 厳密には、 PGDコミット遅延はトランザクションごとの遅延ではありません。これは、特定のクライアント接続のトランザクションストリームにおけるコミット遅延の平均値です。この技術により、コミット遅延と値のきめの細かい調整が、OSスケジューラー、クロック割り込み、およびシステム負荷による変動の粗い粒度をエスケープできます。また、 PGDランタイムコミット遅延を可能な限り最小の期間のマイクロ秒以内に安定させて、遅延測定しきい値を維持できます。 .. Note:: PGDコミット遅延とPostgresコミット遅延を混同しないでください。これらは無関係であり、異なる機能を実行します。一方を他方に置き換えないでください。 !!! トランザクションアプリケーション -------------------------------- PGDコミット遅延は、ユーザーアプリケーションのデータを変更するすべてのREAD WRITEトランザクションに適用されます。この動作は、宣言されたREAD WRITEトランザクションを含む、データを変更しないトランザクションがコミット遅延から免除されることを意味します。 非同期トランザクションのコミットは、 PGDコミット遅延も実行します。これは直観に反しているように見えるかもしれませんが、非同期コミットは、そのパフォーマンスのおかげで、レプリケーション遅延の最大のソースの1つになる可能性があります。 PostgresおよびPGD補助プロセスは、トランザクションのコミット時に遅延しません。最も注目的なのは、PGDライターは、ローカルノードでリモートトランザクションを適用するときにコミット遅延を実行しないことです。 PGDライターは発信レプリケーションラグに何も寄与せず、遅延によってトランザクションコミットが調整されないことにより、着信レプリケーションラグを最も削減できるため、これはデザインです。 制限事項 -------- 最大コミット遅延は、ハード制限を表す天井値であり、コミット遅延が構成された値を超えないことを意味します。逆に、最大遅延はサイズと時間の両方で測定され、超過できるソフト制限です。最大コミット遅延に到達すると、遅延対策に追加のバックプレッシャーはなく、継続的な増加を防ぎます。 PGDレプリケーションセットを変更しないオリジントランザクションをコミット遅延から免除する方法はありません。これらのトランザクションの場合、最大トランザクション遅延を0にSET LOCALにすると役立ちます。 注意事項 -------- アプリケーションTPSは、レプリケーション遅延に影響を与える可能性のある多くの要因の1つです。他の要素には、PGDコミット遅延の効果があまりない可能性があるトランザクションの平均サイズが含まれます。特に、大量のロード操作はレプリケーション遅延の増加を引き起こす可能性があり、これは、最大許容遅延を下回っていますが、通常のアプリケーションで合理的に予想されるレベルを超えてPGDランタイムコミット遅延の付随的な上昇をトリガーする可能性があります。 同様に、非常に高いOLTP要件と適度なデータ変更があるアプリケーションは、許容可能なPGDコミット遅延設定によって不当に抑制される可能性があります。 これらの場合、 ``SET [SESSION|LOCAL]`` コマンドを使用して、これらのアプリケーションのラグ制御設定をカスタム構成するか、これらのアプリケーションを変更すると便利です。たとえば、大量のロード操作は複数の小さなトランザクションに分割されて、トランザクションのスナップショットの期間とWAL保持サイズを制限したり、大量のロードが失敗した場合にリスタートポイントを確立したりする場合があります。ラグ制御を参照して、これらのトランザクションコミットは、非常に長いPGDコミット遅延をスケジュールして、以前の部分的な大量ロードによって発生した遅延をダイジェストすることもできます。 組織目標の達成 -------------- 先ほどの目標リストの例では - 適切な最大ラグタイムを設定することにより、RPOを満たすことができます。 - 適切な最大遅延サイズを設定することにより、RCOを満たすことができます。 - GEOは、PGDランタイムコミット遅延とPGDランタイムラグ対策をモニタリングすることにより満たすことができます。 前述のように、PGDランタイムコミット遅延の最大値がPGD構成済みのコミット遅延制限でペッグされ、遅延測定値が一貫してPGD構成の最大レベルを超える場合、このシナリオはPGDグループ拡張のマーカーになる可能性があります。