Lag Control#

コミットスコープの種類 LAG CONTROL

概要#

Lag Controlは、レプリケーションが設定された制限の外部で実行されている場合、レプリカブル更新を行うトランザクションを処理した後、元のノードのクライアント接続に遅延が注入されるメカニズムを提供します。この遅延は、着信トランザクションを遅くし、定義された制限内にレプリケーションを戻すように設計されています。

背景#

PGD起点ノード上のデータベースアプリケーションのデータスループットは、コミットされたデータをダウンストリームのピアノードに複製できる速度を超える場合があります。

この不均衡が持続すると、RPO、RCO、GEOなどの組織目標の充足が危険にさらされる可能性があります。

RPO 目標復旧ポイントは、計画外のイベントによって失われる可能性のあるデータの最大許容量を指定します。通常は時間として表されます。 PGDでは、RPOは、1つ以上のピアノードに適用されていないコミットされたデータの許容量を決定します。
RCO リソース制約目標は、使用可能なストレージが有限であることを確認します。 PGDでは、遅延が増加すると、これらのストレージリソースの要求が増加します。
GEO グループ弾性目標は、ノードがピアノードに保存できないレートで新しいデータを生成していないことを保証します。

組織が目的を達成できるように、PGDはラグコントロールを提供します。この機能は、データを変更するREAD WRITEトランザクションに遅延を透過的に導入することにより、アプリケーションに侵入することなく、潜在的な不均衡を正確に調整する手段を提供します。この遅延PGDコミット遅延は0ミリ秒で始まります。

LAG CONTROLコミットスコープ種類を使用して、グループ内のノード間でコミットを遅延できる最大時間、最大遅延時間または最大遅延サイズWALのサイズに基づいて、を設定できます。

ノードが十分な数のノードで指定された最大値内でトランザクションを処理できる場合、PGDコミット遅延は0ミリ秒に留まるか、0ミリ秒に向かって削減されます。十分な数のノードで最大値を超えた場合、元のノードのPGDコミット遅延は増加します。十分な数のノードで遅延制御制約が再び満たされるまで、増加し続けます。

PGDコミット遅延は、トランザクションが完了して、すべてのロックとリソースを解放した後に発生します。この遅延のタイミングにより、同時アクティブなトランザクションは、遅延されたトランザクション値の監視と変更、およびそのリソースの取得を続行できます。

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

要件#

Lag Controlの使用を開始するには

すべてのデータベースアプリケーションが許容できる最大許容コミット遅延時間max_commit_delay を決定します。
使用する遅延測定を決定します。ラグサイズmax_lag_size またはラグタイムmax_lag_time のいずれかを選択します。
関係するグループまたはサブグループ、および確認を満たすために必要な各コレクションのノードの最小数を決定します。この情報は、コミットスコープルールの定義の基礎を形成します。

構成#

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

例のように、サブグループとして表される2つのデータセンターleft_dc およびright_dc を含む構成を取得します。

SELECT bdr.create_node_group(
    node_group_name := left_dc,
    parent_group_name := top_group,
    join_node_group := false
);
SELECT bdr.create_node_group(
    node_group_name := right_dc,
    parent_group_name := top_group,
    join_node_group := false
);

次のコードは、サブグループごとに個々のルールを使用して、これらの2つのデータセンターのラグ制御ルールを追加します。

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
);

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

max_commit_delay は間隔であり、通常はミリ秒1ms単位で指定されます。ミリ秒未満の精度での小数値の使用がサポートされています。

max_lag_size は、WALバイト単位で最大許容遅延を指定する整数です。

max_lag_time は、通常秒単位で指定される間隔で、時間に関して最大許容遅延を指定します。

最大コミット遅延 max_commit_delay は、ハード制限を表す天井値であり、コミット遅延が構成値を超えないことを意味します。

最大ラグサイズと時間max_lag_size およびmax_lag_time は、超過できるソフトリミットです。最大コミット遅延に到達すると、遅延対策に追加のバックプレッシャーはなく、継続的な増加を防ぎます。

確認#

Confirmation Level	Lag Control Handling
received	Not applicable, only uses the default VISIBLE.
replicated	Not applicable, only uses the default VISIBLE.
durable	Not applicable, only uses the default VISIBLE.
visible (default)	Not applicable, only uses the default VISIBLE.

トランザクションアプリケーション#

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グループ拡張のマーカーになる可能性があります。

ラグ制御と拡張機能#

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

Lag Control

目次