Durability & Performance Options¶
概要¶
同期またはEager Replicationは、トランザクションをコミットする前にクラスターの少なくとも2つのノード間で同期します。これにより、アプリケーションに関連する3つのプロパティが提供されますが、すべて個別に実装できます。
耐久性：マルチプルのノードに書き込むと、クラッシュ回復力が向上し、クラッシュしてリスタートした後にデータを回復できます。
可視性：クライアントへのコミット確認により、データベースはいくつかのノードセットでのコミットされたトランザクションの即時の可視性を保証します。
コミット後の競合なし：クライアントは、トランザクションが最終的にすべてのノードに適用されることを信頼できます。または、アボートにエラーを直接通知します。
BDRは、同期レプリケーションのバリアントを提供することにより、耐久性と可視性を保証する CAMOとグループコミット 機能を提供します。これは、物理的スタンバイ用のPostgresのsynchronous_commit
機能に非常に似ていますが、ラージ規模な分散システムにより多くの柔軟性を提供します。
Group Commitに加えて、 BDRには2つの追加モードもあります（現在、Group Commitと組み合わせることはできません）。
Commit At Most Once（CAMO）。この機能は、ノードまたはネットワークでCOMMITに障害が発生した場合に、トランザクションがCOMMIT（およびレプリケート）されたかどうかを知ることに関する問題を解決します。通常、 COMMIT が処理されたかどうかを判断するのはハード場合があります。この機能を使用すると、新しいデータベースコネクションが以前の接続とは異なるノードでも、アプリケーションは何が起こったのかを知ることができます。この機能の詳細については、
Commit At Most Once の章を参照してください。
- 熱心な複製。これは、コミットの前に競合をチェックするオプショナルの機能です。すべてのトランザクションはすべてのノードで同時に適用および準備され、レプリケーションの競合が検出されない場合にのみコミットされます。この機能によりパフォーマンスは低下しますが、非常に強い一貫性が保証されます。この機能の詳細については、
Eager All-Node Replicationを使用したCAMO の章を参照してください。
Postgres自分自身は、単方向ですが、 synchronous variant
を提供します。下位互換性のために、 BDRは引き続き synchronous_commit
およびsynchronous_standby_names
を介した同期レプリケーションの構成をサポートしています。
BDRを使用したレガシー同期レプリケーション を参照してくださいが、すべての場合に代わりに CAMOとグループコミット
を使用することをお勧めします。
この章では、さまざまな形式の同期的または一括レプリケーションとそのタイミングの側面について説明します。
用語と定義¶
この章以降の章では、さまざまなロールを担うBDRノードについて説明します。これらはトランザクションごとに暗黙的に割り当てられ、同時トランザクションでも関係ありません。
オリジンはクライアントまたはアプリケーションからトランザクションを受信するノードです。最初にトランザクションを処理し、他のBDRノードへのレプリケーションを開始し、確認またはエラーでクライアントに応答するのはノードです。
パートナーノードは、グループコミットまたはCAMO要件に従ってトランザクションを確認することが期待されるBDRノードです。
コミットグループは、コミットに関係するすべてのBDRノード、つまりオリジンとそのすべてのパートナーノードのグループであり、ほんの一部またはすべての同等なです。
比較¶
BDRで使用可能な同期レプリケーションのほとんどのオプションは、さまざまなレベルの同期を可能にし、パフォーマンスと、ノードまたはネットワークの停止に対する保護との間でさまざまなトレードオフを提供します。
次の表は、トランザクションが発行されたオリジンノードからCOMMIT確認を受け取った後、クライアントがレプリケートされた同等なに期待できるノードをまとめたものです。
「モード」列は、バリアントに応じて異なる意味をとります。
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 |
OSに書き込まれ、OSが実行されたままでPostgresのみがクラッシュする場合。
synchronous_replication_availabilityをasync'に設定してローカルモード（許可されている場合）に切り替えない限り、それ以外の場合は非同期BDRのデフォルトの値が適用されます。
(3)非推奨。代わりにGroup Commitの使用を検討してください。
レセプションは、正常に動作している同等なが、それ以上の通信を必要とせずに、つまり、完全または部分的なネットワーク停止に直面した場合でも、最終的にトランザクションを適用できることを保証します。この確認には永続的なストレージが関係しないため、同等ながクラッシュした場合でもトランザクションの再ノードが必要になる場合があります。同期的と見なされるすべてのモードがこの保護を提供します。
可視性は、トランザクションがリモートで適用されたことを意味し、他のすべてのクライアントは、コミットがオリジンノードによって確認された直後にこの保証を提供するすべてのノードでトランザクションの結果を表示します。可視性がないと、接続されている他のクライアントがトランザクションの結果を表示できず、古い読み取りが発生する場合があります。
耐久性は同等なのストレージに関連し、同等なのクラッシュとリカバリ後のデータの損失に対する保護を提供しノード。これは、データの受信（物理ストリーミングレプリケーションなど）または可視性（グループコミット、CAMO、Eagerなど）に関連します。前者はクラッシュ後の再送信の必要性を排除し、後者はリスタート後も可視性が維持されることを保証します。
操作の内部タイミング¶
さまざまなモードがどのように機能するかをよりよく理解するには、PSRとBDRがトランザクションをかなり異なる方法で適用することを理解すると役立ちます。
物理的ストリーミングレプリケーションの場合、操作のオーダーは次のとおりです。
オリジンはコミットレコードをWALにフラッシュし、トランザクションをローカルに可視にします
同等なは変更を受け取り、書き込みを発行しノード
同等なは受信した変更をディスクにフラッシュします
同等なは変更を適用し、トランザクションをローカルに可視します
BDRでは、操作のオーダーが異なります。
オリジンはコミットレコードをWALにフラッシュし、トランザクションをローカルに可視にします
同等なはメモリの適用キューへの変更を受け取りノード
同等なは変更を適用し、トランザクションをローカルに可視します
同等なはディスクにフラッシュしてトランザクションを持続します
Group Commit、CAMO、およびEagerの場合、オリジンノードはトランザクションをローカルで可視化する前に特定の数の確認を待機することにノートしてください。操作のオーダーは次のとおりです。
オリジンは準備またはプリコミットレコードを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にも適用されます。
計画的なシャットダウンと再起動¶
remote_write
と組み合わせて受信確認またはCAMOを使用する場合、計画的なシャットダウンまたはリスタートに注意する必要があります。デフォルトでは、適用キューはシャットダウンする前に消費されます。ただし、
immediate
シャットダウンモードでは、キューはシャットダウンで破棄され、停止したノードがキュー内のトランザクションを「忘れ」ます。オリジンノードに同時に障害が発生すると、両方のノードに障害が発生したかのように、データが失われる可能性があります。
適用キューがディスクにフラッシュされるように保証には、メンテナンスタスクにsmart
またはfast
シャットダウンを使用してください。これにより、必要な同期レベルが維持され、データの損失が防止されます。
BDRを使用したレガシー同期レプリケーション¶
注釈
このアプローチはお勧めしません。代わりに CAMOとグループコミット の使用を検討してください。
使用法¶
BDRを使用した同期レプリケーションを有効にするには、関連するBDR同等なのアプリケーション名前を
synchronous_standby_names に追加する必要があります。 FIRST x
またはANY x
を使用すると、非BDRスタンバイノードの要件と競合しない場合、ある程度の柔軟性が提供されます。
追加すると、同期のレベルはsynchronous_commit
を介してトランザクションごとに構成できます。デフォルトはon
です。つまり、 synchronous_standby_names
に追加すると同期レプリケーションが有効になります。
synchronous_commit をlocal またはoff
に設定すると、同期レプリケーションがオフになります。
BDRはトランザクションを永続化する前に適用するため、値 on と
remote_apply は同等です（ロジカルレプリケーションの場合）。
グループコミットへの移行¶
BDRのGroup Commit機能は、 synchronous_commit
およびsynchronous_standby_names
から独立して構成されています。代わりに、 bdr.commit_scope
GUCでは、トランザクションごとにスコープを選択できます。また、各ノードで個別に構成されたsynchronous_standby_names
の代わりに、グループコミットはグローバルに同期されたコミットスコープを使用します。
注釈
synchronous_standby_names とコミットスコープの文法は非常に似ていますが、前者はオリジンノードをアカウントしませんが、後者は説明することにノートすることが重要です。したがって、例`synchronous_standby_names = 'ANY 1 (..)'` は`ANY 2 (...)` のコミットスコープと同等です。この選択により、多数決についての推論が容易になり、オリジンノードもトランザクションの耐久性と可視性に貢献することを反映しています。
