Durability and performance options¶
概要¶
EDB Postgres Distributedを使用すると、 コミットスコープ を使用して、耐久性、一貫性、可用性、およびパフォーマンスのニーズに基づいて、いくつかのレプリケーション構成から選択できます。
基本的な構成では、 EDB Postgres
Distributedは非同期レプリケーションを使用します。ただし、コミットスコープは、デフォルトとトランザクションごとの動作の両方を変更できます。組み込みの物理または論理レプリケーションと同じ方法で、標準のsynchronous_standby_names
を使用して、レガシーPostgres同期レプリケーションを構成することもできます。ただし、コミットスコープを使用すると、レプリケーション動作をはるかに柔軟に制御できます。
さまざまな同期設定は、関連するアプリケーションに関連する3つのプロパティに影響しますが、すべて個別に実装できます。
耐久性：複数のノードに書き込むと、クラッシュ回復力が向上し、クラッシュして再起動した後にデータを回復できます。
可視性 ：クライアントへのコミット確認により、データベースはいくつかのノードセットでコミットされたトランザクションの即時の可視性を保証します。
競合処理 ：競合はコミット後に楽観的に処理でき、コミットタイムスタンプに基づいてトランザクションがレプリケートされるときに競合が解決されます。または、プリコミットで悲観的に処理できます。クライアントは、トランザクションが最終的にすべてのノードに適用されることを信頼できます。これ以上競合することはありません。アボートして、クライアントにエラーを直接通知できます。
コミットスコープを使用すると、トランザクションの持続性を制御する2つの方法を使用できます。
Group Commit 。このオプションは、トランザクションがコミット可能と見なされる前にコンセンサスに達する必要があるノードとノード数、およびレプリケーションのどの段階でコミットされたと見なされるかを制御します。このオプションを使用すると、トランザクションの可視性の順序を制御することもできます。
CAMO/failoverオプションを使用したpgbench 。このオプションは、クライアントがコンセンサスの一部であるGroup Commitのバリアントです。
Lag Control 。このオプションは、コミットの続行を許可する前に、レプリケーションに関してノードからどれだけ遅れることができるかを制御します。
Postgresは physical streaming replication を提供します
（PSR）単方向ですが、 synchronous variant
を提供します。下位互換性のため、PGDは引き続き synchronous_commit
およびsynchronous_standby_names
を使用した同期レプリケーションの構成をサポートしています。
PGDを使用したレガシー同期レプリケーション を参照してくださいが、代わりに Group Commit
の使用を検討してください。
用語と定義¶
PGDノードは、トランザクションのレプリケーション中にさまざまな役割を果たします。これらはトランザクションごとに暗黙的に割り当てられ、同時トランザクションでも関係ありません。
** オリジン*は、クライアントまたはアプリケーションからトランザクションを受信するノードです。最初にトランザクションを処理するのはノードであり、他のPGDノードへのレプリケーションを開始し、確認またはエラーでクライアントに応答します。
** パートナー*ノードは、グループコミット要件に従ってトランザクションを確認することが期待されるPGDノードです。
** コミットグループ*は、コミットに関与するすべてのPGDノード、つまり、オリジンとそのすべてのパートナーノードのグループであり、少数またはすべてのピアノードになります。
比較¶
PGDで利用可能な同期レプリケーションのほとんどのオプションは、さまざまなレベルの同期を可能にし、パフォーマンスと、ノードまたはネットワークの停止に対する保護との間のさまざまなトレードオフを提供します。
次の表は、トランザクションが発行されたオリジンノードからCOMMIT確認を受信した後、クライアントがレプリケートされたピアノードに期待できることをまとめたものです。
Mode列は、バリアントに応じて異なる意味をとります。
PSRとPGDを使用したレガシー同期レプリケーションの場合、
synchronous_commit 設定を指します。コミットスコープの場合、
commit scope configuration の確認要件を指します。
Variant |
Mode |
Received |
Visible |
Durable |
|---|---|---|---|---|
PSR Async |
off (default) |
no |
no |
no |
PGD Async |
off (default) |
no |
no |
no |
PGD Lag Control |
'ON received' nodes |
no |
no |
no |
PGD Lag Control |
'ON replicated' nodes |
no |
no |
no |
PGD Lag Control |
'ON durable' nodes |
no |
no |
no |
PGD Lag Control |
'ON visible' nodes |
no |
no |
no |
PSR Sync |
remote_write (2) |
yes |
no |
no (1) |
PSR Sync |
on (2) |
yes |
no |
yes |
PSR Sync |
remote_apply (2) |
yes |
yes |
yes |
PGD Group Commit |
'ON received' nodes |
yes |
no |
no |
PGD Group Commit |
'ON replicated' nodes |
yes |
no |
no |
PGD Group Commit |
'ON durable' nodes |
yes |
no |
yes |
PGD Group Commit |
'ON visible' nodes |
yes |
yes |
yes |
PGD CAMO |
'ON received' nodes |
yes |
no |
no |
PGD CAMO |
'ON replicated' nodes |
yes |
no |
no |
PGD CAMO |
'ON durable' nodes |
yes |
no |
yes |
PGD CAMO |
'ON visible' nodes |
yes |
yes |
yes |
PGD Legacy Sync (3) |
remote_write (2) |
yes |
no |
no |
PGD Legacy Sync (3) |
on (2) |
yes |
yes |
yes |
PGD Legacy Sync (3) |
remote_apply (2) |
yes |
yes |
yes |
（1）OSに書き込まれ、OSが実行されたままでPostgresのみがクラッシュする場合。
（2）
synchronous_replication_availabilityをasync'に設定してローカルモード（許可されている場合）に切り替えない限り、それ以外の場合は非同期PGDのデフォルトの値が適用されます。
（3）代わりにGroupCommitの使用を検討してください。
受信により、正常に動作しているピアが、ネットワーク全体または部分的な停止に直面した場合でも、それ以上の通信を必要とせずに最終的にトランザクションを適用できることが保証されます。この確認には永続ストレージが関係しないため、ピアノードのクラッシュには引き続きトランザクションの再送信が必要な場合があります。同期と見なされるすべてのモードがこの保護を提供します。
可視性は、トランザクションがリモートで適用されたことを意味します。他のすべてのクライアントは、すべてのノードでトランザクションの結果を確認し、コミットがオリジンノードによって確認された直後にこの保証を提供します。可視性がなければ、接続されている他のクライアントはトランザクションの結果を表示できず、古い読み取りが発生する可能性があります。
耐久性はピアノードのストレージに関連し、ピアノードのクラッシュと回復後のデータの損失に対する保護を提供します。これは、データの受信（物理ストリーミングレプリケーションなど）または可視性（Group Commitなど）に関連する可能性があります。前者はクラッシュ後の再送信の必要性を排除し、後者は再起動後も可視性が維持されることを保証します。
操作の内部タイミング¶
さまざまなモードがどのように機能するかをよりよく理解するには、PSRとPGDがトランザクションを異なる方法で適用することを理解すると役立ちます。
物理ストリーミングレプリケーション、操作の順序は次のとおりです。
OriginはコミットレコードをWALにフラッシュし、トランザクションをローカルで見えるようにします。
ピアノードは変更を受け取り、書き込みを発行します。
ピアは、受け取った変更をディスクにフラッシュします。
ピアは変更を適用し、トランザクションをローカルで見えるようにします。
PGDでは、操作の順序が異なります。
OriginはコミットレコードをWALにフラッシュし、トランザクションをローカルで見えるようにします。
ピアノードは、メモリ内の適用キューへの変更を受け取ります。
ピアは変更を適用し、トランザクションをローカルで見えるようにします。
ピアは、ディスクにフラッシュすることによりトランザクションを永続化します。
Group Commit、 CAMO、およびEagerの場合、オリジンノードはトランザクションをローカルで可視化する前に特定の数の確認を待機します。操作の順序は次のとおりです。
Originは、準備またはプリコミットレコードをWALにフラッシュします。
ピアノードは、メモリ内の適用キューへの変更を受け取ります。
ピアは変更を適用し、トランザクションをローカルで見えるようにします。
ピアは、ディスクにフラッシュすることによりトランザクションを永続化します。
Originはコミットしてトランザクションをローカルで可視にします。
次の表は、違いをまとめたものです。
Variant |
Order of apply vs persist |
Replication before or after commit |
|---|---|---|
PSR |
persist first |
after WAL flush of commit record |
PGD Async |
apply first |
after WAL flush of commit record |
PGD Lag Control |
apply first |
after WAL flush of commit record |
PGD Group Commit |
apply first |
before COMMIT on origin |
PGD CAMO |
apply first |
before COMMIT on origin |
構成¶
PGDでの他の管理操作と同様に、 SQL関数を使用してコミットスコープを構成します。
たとえば、 example_group PGDグループの大部分のノードでグループコミットを行う基本的なコミットスコープを定義できます。
SELECT bdr.add_commit_scope(
commit_scope_name := example_scope,
origin_node_group := example_group,
rule := ANY MAJORITY (example_group) GROUP COMMIT,
wait_for_ready := true
);
次に、トランザクションごとにまたはグローバルに構成変数（GUC）bdr.commit_scope
をそのコミットスコープに設定することにより、コミットスコープを使用できます。
BEGIN;
SET LOCAL bdr.commit_scope = example_scope;
...
COMMIT;
特定のPGDグループのデフォルトのコミットスコープを設定することもできます。
SELECT bdr.alter_node_group_option(
node_group_name := example_group,
config_key := default_commit_scope,
config_value := example_scope
);
default_commit_scope
は、指定された起点ノードが属するグループツリーで下から上にチェックされます。
default_commit_scope は特別な値local
に設定できません。これは、コミットスコープがbdr.commit_scope
構成パラメーターを使用する方法がないことを意味します。
- 説明されているすべてのオプションを含むコミットスコープ言語の完全な詳細については、
commitスコープへの移行 を参照してください。
Postgres構成パラメーター¶
次の表に、デフォルト以外の値（req）に設定する必要がある構成設定と、オプション（opt）であるが特定のバリアントに影響を与える構成設定の概要を示します。
Setting (GUC) |
Group Commit |
Lag Control |
PSR (1) |
Legacy Sync |
|---|---|---|---|---|
synchronous_standby_names |
n/a |
n/a |
req |
req |
synchronous_commit |
n/a |
n/a |
opt |
opt |
synchronous_replication_availability |
n/a |
n/a |
opt |
opt |
bdr.commit_scope |
opt |
opt |
n/a |
n/a |
計画的なシャットダウンと再起動¶
受信確認でGroup
Commitを使用する場合は、計画的なシャットダウンまたは再起動に注意してください。デフォルトでは、適用キューはシャットダウン前に消費されます。ただし、
immediate
シャットダウンモードでは、シャットダウン時にキューが破棄され、停止したノードがキュー内のトランザクションを「忘れ」ます。起点ノードの同時障害は、両方のノードに障害が発生したかのように、データの損失につながる可能性があります。
適用キューがディスクにフラッシュされるようにするには、メンテナンスタスクにsmart
またはfast
shutdownを使用します。このアプローチにより、必要な同期レベルが維持され、データの損失が防止されます。
PGDを使用したレガシー同期レプリケーション¶
注釈
代わりに Group Commit の使用を検討してください。
使用法¶
PGDを使用して同期レプリケーションを有効にするには、関連するPGDピアノードのアプリケーション名をsynchronous_standby_names
に追加する必要があります。 FIRST x またはANY x
の使用は、非PGDスタンバイノードの要件と競合しない場合、ある程度の柔軟性を提供します。
追加したら、 synchronous_commit
を使用して、トランザクションごとの同期レベルを構成できます。デフォルトはon
です。この設定は、アプリケーション名をsynchronous_standby_names
に追加すると既に同期レプリケーションが有効になっていることを意味します。
synchronous_commit をlocal またはoff
に設定すると、同期レプリケーションがオフになります。
PGDはトランザクションを永続化する前に適用するため、値 on および
remote_apply 論理レプリケーションと同等です。
commitスコープへの移行¶
synchronous_commit およびsynchronous_standby_names
とは無関係に、PGDのグループコミット機能を構成します。代わりに、
bdr.commit_scope
GUCを使用すると、トランザクションごとにスコープを選択できます。また、各ノードでsynchronous_standby_names
を個別に構成する代わりに、Group
Commitはグローバルに同期されたコミットスコープを使用します。
注釈
synchronous_standby_names とcommitスコープの文法は似ていますが、前者は起点ノードを説明しませんが、後者は説明します。したがって、たとえば、 synchronous_standby_names = 'ANY 1 (..)' は`ANY 2 (...)` のコミットスコープと同等です。この選択により、多数決についての推論が容易になり、オリジンノードがトランザクションの耐久性と可視性にも貢献することを反映しています。
