Durability#
概要#
EDB Postgres分散では、 コミットスコープ を使用して、耐久性、一貫性、可用性、およびパフォーマンスのニーズに基づいて、いくつかのレプリケーション構成から選択できます。
基本的な構成では、 EDB
Postgres分散は非同期レプリケーションを使用します。ただし、コミットスコープは、デフォルトとトランザクションごとの動作の両方を変更できます。ビルトインの物理または論理レプリケーションと同じ方法で、標準のsynchronous_standby_names
を使用して古いPostgres同期レプリケーションを構成することもできます。ただし、コミットスコープは、レプリケーション動作の柔軟性と制御を提供します。
さまざまな同期設定は、関連しているがすべて個別に実装できるアプリケーションの3つのプロパティに影響を与えます。
耐久性 複数のノードに書き込むと、クラッシュ耐性が向上し、クラッシュと再起動後にデータを復旧できます。
可視性 クライアントへのコミット確認により、データベースは、一部のノードセットでコミットされたトランザクションの即時の可視性を保証します。
競合処理 競合はコミット後に楽観的に処理でき、コミットタイムスタンプに基づいてトランザクションがレプリケートされるときに競合が解決されます。または、プリコミット時に悲観的に処理できます。クライアントは、最終的にすべてのノードに適用されるトランザクションに依存して、さらなる競合または中止を取得して、クライアントにエラーを直接通知できます。
コミットスコープでは、トランザクションの持続性を制御する2つの方法ができます。
グループコミット 。このオプションは、トランザクションがコミット可能であると考えられる前に、どのノードといくつのノードがコンセンサスに到達する必要があるか、およびレプリケーションのどの段階でコミットされたと考えられるかを制御します。このオプションを使用すると、トランザクションの可視性の順序を制御することもできます。
CAMOまたはコミット・アット・モスト・ワンス 。このオプションは、クライアントがコンセンサスに参加するグループコミットのバリアントです。
遅延制御 。このオプションは、コミットを続行する前に、レプリケーションの点でノードがどれだけ遅れていてもよいかを制御します。
Postgresは physical streaming replication を提供します
PSR、これは一方向ですが synchronous variant
を提供します。下位互換性を維持するために、PGDはsynchronous_commit
およびsynchronous_standby_names
を使用した同期レプリケーションの構成を引き続きサポートしています。
PGDを使用したレガシー同期レプリケーション を参照してくださいが、代わりに グループコミット の使用を検討します。
用語と定義#
PGDノードは、トランザクションのレプリケーション中にさまざまなロールを引き受けます。これらはトランザクションごとに暗黙的に割り当てられ、同時トランザクションの場合でも関係ありません。
** origin*は、クライアントまたはアプリケーションからトランザクションを受信するノードです。最初にトランザクションを処理するノードであり、他の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のみがクラッシュした場合に持続します。
synchronous_replication_availabilityをasync'に設定してローカルモードに切り替えない限り、許可されている場合。それ以外の場合、非同期PGDデフォルトの値が適用されます。
(3) 代わりにグループコミットの使用を検討します。
受信により、通常に動作しているピアは、完全または部分的なネットワークの停止が発生した場合でも、最終的に追加の通信を必要とせずにトランザクションを適用できます。この確認には永続ストレージが関係しないため、ピアノードがクラッシュしてもトランザクションの再送信が必要になる場合があります。同期と考えられるすべてのモードがこの保護を提供します。
可視性は、トランザクションがリモートで適用されたことを示します。他のすべてのクライアントは、すべてのノードでトランザクションの結果を確認します。元のノードによってコミットが確認された直後にこの保証を提供します。可視性がないと、接続している他のクライアントはトランザクションの結果を認識せず、古い読み取りを経験する可能性があります。
耐久性は、ピアノードのストレージに関連し、ピアノードのクラッシュと復旧後のデータの損失に対する保護を提供します。これは、データの受信物理的ストリーミングレプリケーションの場合または可視性グループコミットの場合のいずれかに関連します。前者により、クラッシュ後の再送信の必要がなくなり、後者により、再起動しても可視性が維持されます。
操作の内部タイミング#
さまざまなモードがどのように動作するかをより深く理解するために、PSRとPGDはトランザクションを異なる方法で適用することを理解すると役立ちます。
物理的ストリーミングレプリケーションを使用する場合、操作の順序は次のとおりです。
オリジンはコミットレコードをWALにフラッシュし、トランザクションをローカルに認識できるようにします。
ピアノードは変更を受信し、書き込みを発行します。
ピアは、受信した変更をディスクにフラッシュします。
ピアは変更を適用し、トランザクションをローカルに認識できるようにします。
PGDでは、操作の順序が異なります。
オリジンはコミットレコードを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
構成パラメーターを使用する方法がないことを意味します。
- 説明したすべてのオプションを含むコミットスコープ言語の詳細については、
コミットスコープ を参照してください。
Postgres構成パラメーター#
次の表は、デフォルト以外の値に設定する必要がある構成設定reqと、オプショナルですが特定のバリアントに影響を与える構成設定の概要を提供します。
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 |
計画的なシャットダウンと再起動#
受信確認でグループコミットを使用する場合、計画的なシャットダウンまたは再起動に注意してください。デフォルトでは、適用キューはシャットダウンの前に消費されます。ただし、
immediate
シャットダウンモードでは、シャットダウン時にキューは破棄されるため、停止したノードはキュー内のトランザクションを「忘れ」ます。元のノードに同時に障害が発生すると、両方のノードに障害が発生したかのように、データの損失が発生する可能性があります。
適用キューがディスクにフラッシュされるようにするには、メンテナンスタスクにsmart
またはfast
シャットダウンを使用します。このアプローチでは、必要な同期レベルを維持し、データの損失を防ぎます。
PGDを使用したレガシー同期レプリケーション#
注釈
代わりに グループコミット の使用を検討します。
使用法#
PGDを使用した同期レプリケーションを有効にするには、関連するPGDピアノードのアプリケーション名をsynchronous_standby_names
に追加する必要があります。 FIRST x またはANY x
を使用すると、非PGDスタンバイノードの要件と競合しない場合、ある程度の柔軟性が提供されます。
追加したら、 synchronous_commit
を使用してトランザクションごとの同期レベルを構成できます。デフォルトはon
です。この設定は、アプリケーション名をsynchronous_standby_names
に追加することにより、既に同期レプリケーションが有効になっていることを意味します。
synchronous_commit をlocal またはoff
に設定すると、同期レプリケーションがオフになります。
PGDは永続化する前にトランザクションを適用するため、値on
およびremote_apply は論理レプリケーションでは等価です。
コミットスコープへの移行#
synchronous_commit およびsynchronous_standby_names
とは無関係に、PGDのグループコミット機能を構成します。代わりに、bdr.commit_scope
GUCを使用すると、トランザクションごとにスコープを選択できます。また、各ノードでsynchronous_standby_names
を個別に構成するのではなく、グループコミットはグローバルに同期したコミットスコープを使用します。
注釈
synchronous_standby_names およびコミットスコープの文法は似ていますが、前者はオリジンノードを考慮していませんが、後者は考慮します。したがって、たとえば synchronous_standby_names = 'ANY 1 (..)' は、ANY 2 (...) のコミットスコープと同等です。この選択により、マジョリティに関する推論が簡単になり、起点ノードがトランザクションの耐久性と可視性にも貢献することを反映しています。