Durability and performance options¶
概要¶
同期または * Eager Replication*は、トランザクションをコミットする前にクラスターの少なくとも2つのノード間で同期します。この同期は、関連するがすべて個別に実装できるアプリケーションに関連する 3 つのプロパティを提供します。
耐久性：複数のノードに書き込むと、クラッシュ回復力が向上し、クラッシュして再起動した後にデータを回復できます。
可視性：クライアントへのコミット確認により、データベースはいくつかのノードセットでのコミットされたトランザクションの即時の可視性を保証します。
コミット後に競合なし：クライアントは、トランザクションが最終的にすべてのノードに適用されることを信頼したり、クライアントにエラーを直接通知したりできます。
BDRは、同期レプリケーションのバリアントを提供することにより、耐久性と可視性を保証する CAMOとグループコミット 機能を提供します。この機能は、フィジカルスタンバイ用のPostgres
synchronous_commit
機能に似ていますが、大規模な分散システムにより多くの柔軟性を提供します。
Group Commitに加えて、 BDRは現在Group Commitと組み合わせることができない他の2つのモードも提供しています。
Commit At Most Once（CAMO）。この機能は、ノードまたはネットワークに障害が発生した場合にトランザクションがコミット（およびレプリケート）されたかどうかを知ることに関する問題を解決します。通常、 COMMIT が処理されたかどうかを知るのは難しい場合があります。この機能を使用すると、新しいデータベース接続が以前の接続とは異なる場合でも、アプリケーションは何が起こったのかを知ることができます。この機能の詳細については、
Commit At Most Once を参照してください。
Eager Replication。これは、コミットの前に競合をチェックするオプションの機能です。すべてのトランザクションはすべてのノードで同時に適用および準備され、レプリケーションの競合が検出されない場合にのみコミットされます。この機能により、パフォーマンスは低下しますが、強い一貫性が保証されます。この機能の詳細については、
Eager All-Node Replicationを使用したCAMO を参照してください。
Postgresは、単方向ですが synchronous variant を提供する Physical Streaming Replication
（PSR）を提供します。下位互換性のために、 BDRは引き続き
synchronous_commit およびsynchronous_standby_names
を使用した同期レプリケーションの構成をサポートしています。
BDRを使用したレガシー同期レプリケーション を参照してくださいが、すべての場合に代わりに CAMOとグループコミット
を使用することをお勧めします。
用語と定義¶
BDRノードはさまざまなロールを取ることができます。これらはトランザクションごとに暗黙的に割り当てられ、同時トランザクションでも関係ありません。
オリジンは、クライアントまたはアプリケーションからトランザクションを受信するノードです。最初にトランザクションを処理し、他のBDRノードへのレプリケーションを開始し、確認またはエラーでクライアントに応答するのはノードです。
パートナーノードは、グループコミットまたはCAMO要件に従ってトランザクションを確認することが期待されるBDRノードです。
コミットグループは、コミットに関係するすべてのBDRノード、つまりオリジンとそのすべてのパートナーノードのグループであり、少数またはすべてのピアノードです。
比較¶
BDRで使用可能な同期レプリケーションのほとんどのオプションは、さまざまなレベルの同期を可能にし、パフォーマンスと、ノードまたはネットワークの停止に対する保護との間でさまざまなトレードオフを提供します。
次の表は、トランザクションが発行されたオリジンノードからCOMMIT確認を受け取った後、クライアントがレプリケートされたピアノードに期待できることをまとめたものです。
Mode列は、バリアントに応じて異なる意味をとります。
BDRを使用したPSRおよびレガシー同期レプリケーションの場合、
synchronous_commit 設定を参照します。 CAMOの場合、
bdr.enable_camo 設定を指します。また、Group Commitの場合、
commit scope configuration の確認要件を参照します。
Variant |
Mode |
Received |
Visible |
Durable |
|---|---|---|---|---|
async BDR |
off (default) |
no |
no |
no |
PSR |
remote_write (2) |
yes |
no |
no (1) |
PSR |
on (2) |
yes |
no |
yes |
PSR |
remote_apply (2) |
yes |
yes |
yes |
Group Commit |
'ON received' nodes |
yes |
no |
no |
Group Commit |
'ON replicated' nodes |
yes |
no |
no |
Group Commit |
'ON durable' nodes |
yes |
no |
yes |
Group Commit |
'ON visible' nodes |
yes |
yes |
yes |
CAMO |
remote_write (2) |
yes |
no |
no |
CAMO |
remote_commit_async (2) |
yes |
yes |
no |
CAMO |
remote_commit_flush (2) |
yes |
yes |
yes |
Eager |
n/a |
yes |
yes |
yes |
legacy (3) |
remote_write (2) |
yes |
no |
no |
legacy (3) |
on (2) |
yes |
yes |
yes |
legacy (3) |
remote_apply (2) |
yes |
yes |
yes |
（1）OSに書き込まれ、OSが実行されたままでPostgresのみがクラッシュする場合。
synchronous_replication_availabilityをasync'に設定してローカルモードに切り替えない限り（許可されている場合）、それ以外の場合は非同期BDRのデフォルトの値が適用されます。
(3)非推奨。代わりにGroup Commitの使用を検討してください。
受信により、ネットワーク全体または部分的な障害が発生した場合でも、正常に動作しているピアが最終的にそれ以上の通信を必要とせずにトランザクションを適用できることが保証されます。この確認には永続ストレージが関係しないため、ピアノードがクラッシュした場合でもトランザクションの再送信が必要になる場合があります。同期と見なされるすべてのモードがこの保護を提供します。
可視性は、トランザクションがリモートで適用されたことを意味します。他のすべてのクライアントは、コミットがオリジンノードによって確認された直後にこの保証を提供すると、すべてのノードでトランザクションの結果を表示します。可視性がないと、接続されている他のクライアントがトランザクションの結果を表示できず、古い読み取りが発生する可能性があります。
耐久性はピアノードのストレージに関連し、ピアノードのクラッシュと復旧後のデータの損失に対する保護を提供します。これは、データの受信（物理ストリーミングレプリケーションなど）または可視性（Group Commit、 CAMO、およびEagerなど）に関連します。前者はクラッシュ後の再送信の必要性を排除し、後者はリスタート後も可視性が維持されることを保証します。
操作の内部タイミング¶
さまざまなモードがどのように機能するかをよりよく理解するには、PSRとBDRがトランザクションを異なる方法で適用することを理解すると役立ちます。
物理ストリーミングレプリケーションの場合、操作の順序は次のとおりです。
OriginはコミットレコードをWALにフラッシュし、トランザクションをローカルで可視にします。
ピアノードは変更を受け取り、書き込みを発行します。
ピアは受信した変更をディスクにフラッシュします。
ピアは変更を適用し、トランザクションをローカルに表示します。
BDRでは、操作の順序が異なります。
OriginはコミットレコードをWALにフラッシュし、トランザクションをローカルで可視にします。
ピアノードは、メモリ内の適用キューへの変更を受け取ります。
ピアは変更を適用し、トランザクションをローカルに表示します。
ピアは、ディスクにフラッシュすることによりトランザクションを永続化します。
Group Commit、 CAMO、およびEagerの場合、オリジンノードはトランザクションをローカルで可視化する前に特定の数の確認を待機します。操作の順序は次のとおりです。
Originは、準備またはプリコミットレコードをWALにフラッシュします。
ピアノードは、メモリ内の適用キューへの変更を受け取ります。
ピアは変更を適用し、トランザクションをローカルに表示します。
ピアは、ディスクにフラッシュすることによりトランザクションを永続化します。
オリジンはトランザクションをコミットしてローカルに表示します。
次の表は、違いをまとめたものです。
Variant |
Order of apply vs persist |
Replication before or after commit |
|---|---|---|
PSR |
persist first |
after WAL flush of commit record |
BDR |
apply first |
after WAL flush of commit record |
Group Commit |
apply first |
before COMMIT on origin |
CAMO |
apply first |
before COMMIT on origin |
Eager |
apply first |
before COMMIT on origin |
構成¶
次の表は、デフォルト以外の値（req）またはオプション（opt）に設定する必要があるが、特定のバリアントに影響を与える構成設定の概要を示しています。
setting (GUC) |
Group Commit |
CAMO |
Eager |
PSR (1) |
|---|---|---|---|---|
synchronous_standby_names |
n/a |
n/a |
n/a |
req |
synchronous_commit |
n/a |
n/a |
n/a |
opt |
synchronous_replication_availability |
n/a |
opt |
n/a |
opt |
bdr.enable_camo |
n/a |
req |
n/a |
n/a |
bdr.commit_scope |
req |
n/a |
opt |
n/a |
bdr.global_commit_timeout |
opt |
opt |
opt |
n/a |
（1）この列の値は、 BDRと組み合わせて使用されている
synchronous_commitおよびsynchronous_standby_namesにも適用されます。
計画的なシャットダウンと再起動¶
受信確認またはCAMOをremote_write と組み合わせてGroup
Commitを使用する場合、計画的なシャットダウンまたは再起動に注意してください。デフォルトでは、適用キューはシャットダウンする前に消費されます。ただし、
immediate
シャットダウンモードでは、シャットダウン時にキューが破棄されるため、停止したノードがキュー内のトランザクションを「削除」します。起点ノードに同時に障害が発生すると、両方のノードに障害が発生したかのように、データが失われる可能性があります。
適用キューがディスクにフラッシュされるようにするには、メンテナンスタスクに
smart または fast
shutdownを使用します。このアプローチにより、必要な同期レベルが維持され、データの損失が防止されます。
BDRを使用したレガシー同期レプリケーション¶
注釈
このアプローチはお勧めしません。代わりに CAMOとグループコミット の使用を検討してください。
使用法¶
BDRを使用して同期レプリケーションを有効にするには、関連するBDRピアノードのアプリケーション名を
synchronous_standby_names に追加する必要があります。 FIRST x
またはANY x
の使用は、非BDRスタンバイノードの要件と競合しない限り、ある程度の柔軟性を提供します。
追加したら、デフォルトはon であるsynchronous_commit
を使用して、トランザクションごとの同期レベルを構成できます。この設定は、
synchronous_standby_names
に追加すると既に同期レプリケーションが有効になっていることを意味します。
synchronous_commit をlocal またはoff
に設定すると、同期レプリケーションがオフになります。
BDRはトランザクションを永続化する前に適用するため、値 on と
remote_apply は同等です（論理レプリケーションの場合）。
グループコミットへの移行¶
BDRのグループコミット機能は、 synchronous_commit
およびsynchronous_standby_names
から独立して構成されています。代わりに、 bdr.commit_scope
GUCでは、トランザクションごとにスコープを選択できます。また、各ノードで個別に構成されたsynchronous_standby_names
の代わりに、グループコミットはグローバルに同期されたコミットスコープを使用します。
注釈
synchronous_standby_names とCommit Scopesの文法は似ていますが、前者は起点ノードを説明しませんが、後者は説明します。したがって、たとえば、 synchronous_standby_names = 'ANY 1 (..)' は`ANY 2 (...)` のコミットスコープと同等です。この選択により、多数決についての推論が容易になり、オリジンノードがトランザクションの耐久性と可視性にも寄与することを反映しています。
