Architectural overview¶

BDRは、メッシュトポロジを使用して、疎結合のマルチマスター論理レプリケーションを提供します。これは、任意のサーバーに書き込むことができ、変更は同じBDRグループに属する他のすべてのサーバーに行ごとに直接送信されることを意味します。

デフォルトでは、 BDRは非同期レプリケーションを使用し、ローカルコミット後にのみピアノードに変更を適用します。オプションの Eager All-Node Replicationを使用したCAMO 機能により、コンセンサスを使用してすべてのノードでコミットできます。

基本的なアーキテクチャ¶

複数のグループ¶

BDRノードは少なくとも1つのノードグループのメンバーであり、最も基本的なアーキテクチャでは、 BDRクラスター全体に1つのノードグループがあります。

複数のマスター¶

BDRグループに参加する各ノード（データベース）は、他のメンバーから変更を受け取り、ユーザが直接書き込むことができます。

これは、1つのマスターサーバーのみが書き込みを受け入れ、他のすべてのノードがマスターまたは別のスタンバイから複製するホットまたはウォームスタンバイとは異なります。

常にすべてのマスターに書き込む必要はありません。頻繁な構成では、ほとんどの場合、1つのマスターのみに書き込みを指示します。

デフォルトでは非同期¶

1つのBDRノードで行われた変更は、ローカルにコミットされるまで他のノードにレプリケートされません。その結果、データは常にすべてのノードで完全に同じではありません。一部のノードには、他のノードにまだ到達していないデータがあります。 PostgreSQLのブロックベースのレプリケーションソリューションもデフォルトで非同期レプリケーションです。 BDRでは、マスターが複数あり、その結果、データストリームが複数になるため、 synchronous_commit および synchronous_standby_names を使用した場合でも、異なるノード上のデータが異なる場合があります。

メッシュトポロジー¶

BDRは、すべてのノードが他のすべてのノードに接続し、すべてのノードが相互に直接データを交換するメッシュネットワークを中心に構成されています。ノードの追加や削除などの特別な状況を除き、 BDRでのデータの転送はありません。データはEDB Postgres分散クラスターの外部から到着するか、ネイティブのPostgreSQL論理レプリケーションを使用して送信できます。

論理レプリケーション¶

論理レプリケーションは、レプリケーションID（通常は主キー）に基づいてデータ行とその変更をレプリケートする方法です。正確なブロックアドレスとバイトごとのレプリケーションを使用する物理レプリケーションとは対照的に、論理という用語を使用します。インデックスの変更は複製されないため、書き込みの増幅が回避され、帯域幅が削減されます。

論理レプリケーションは、ソースノードからデータのスナップショットをコピーすることから始まります。それが完了すると、後のコミットはリアルタイムで発生すると他のノードに送信されます。変更はSQLを再実行せずに複製されるため、書き込まれた正確なデータが迅速かつ正確に複製されます。

ノードはソースノードでコミットされた順序でデータを適用するため、単一ノードからの変更に対してトランザクションの一貫性が保証されます。異なるノードからの変更は他のノードとは無関係に適用され、変更の迅速なレプリケーションが保証されます。

レプリケートされたデータは、安全な場合にバイナリ形式で送信されます。

高可用性¶

各マスターノードは1つ以上のスタンバイノードで保護できるため、ダウンしたノードをすばやく交換して続行できます。各スタンバイノードは、論理スタンバイノードまたはフィジカルスタンバイノードのいずれかです。

1つ以上のノードが現在利用できない場合でも、レプリケーションは現在接続されているノード間で続行されます。ノードが回復すると、レプリケーションを中断したところから再開できます。

ノードはさまざまなリリースレベルを実行し、通信に必要なプロトコルをネゴシエートできます。その結果、 EDB Postgres分散クラスターは、データベースソフトウェアのメジャーバージョンでも、ローリングアップグレードを使用できます。

DDLはデフォルトでノード間で複製されます。 DDLの実行は、必要に応じてユーザーが制御して、アプリケーションのローリングアップグレードを許可できます。

制限¶

BDRは、十分なハードウェアとネットワークで数百のノードを実行できます。ただし、メッシュベースの展開では、通常、1つのクラスターで32を超えるノードを実行することはお勧めしません。各マスターノードは、複数のフィジカルまたはロジカルスタンバイノードで保護できます。スタンバイノードの数に特に制限はありませんが、一般的な使用法はマスターごとに2〜3個のスタンバイを持つことです。スタンバイノードはメッシュネットワークに接続を追加しないため、32ノードの推奨には含まれません。

BDRには、現在許可されている現在の最大Raft接続であるため、1000アクティブノードのハード制限があります。

BDRは、1つのPostgreSQLインスタンスで最大10個のデータベースが異なるBDRノードグループのBDRノードにできるという制限を設けています。ただし、 BDRは、PostgreSQLインスタンスごとに1つのBDRデータベースのみを使用する場合に最適に機能します。

BDRのコンセンサスメカニズムにフォールトトレランスを提供するための、 EDB Postgres分散クラスターの推奨されるノードの最小数は3です。 2つのノードだけでは、いずれかのノードが応答しないとコンセンサスは失敗します。分散シーケンス生成などの一部のBDR操作にはコンセンサスが必要です。 EDB Postgres Distributedで使用されるコンセンサスメカニズムの詳細については、

Architectural details を参照してください。

アーキテクチャのオプションとパフォーマンス¶

BDRパフォーマンスの特徴付け¶

BDRは、それぞれが異なるパフォーマンスとスケーラビリティ特性を持つ多数の異なるアーキテクチャで構成できます。

グループは、2つ以上のノード（サーバー）で構成されるBDRグループの基本的なビルディングブロックです。グループでは、各ノードは専用のルーターとバックアップを使用して異なるアベイラビリティーゾーンにあり、即時のスイッチオーバーと高可用性が提供されます。各グループには、専用のレプリケーションセットが定義されています。グループがノードを失った場合、グループから既存のノードをコピーすることにより、簡単に修復または置換できます。

BDRはすべてのノードですべての書き込みを再生する必要があるため、ほとんどのテーブルがレプリケートされる場合、 BDRグループにマスターノードを追加しても大幅な書き込みスループットの向上はありません。 BDR書き込みは一般に、 SQLを介したPostgresクライアントからの書き込みよりも効果的であるため、パフォーマンスをいくらか向上させることができます。読み取りスループットは通常、ノード数に比例して増加します。

次のアーキテクチャを使用できます。

マルチマスター/シングルグループ
BDR AlwaysOn

最も単純なアーキテクチャは、グループを1つだけにすることです。

1つのグループでのBDRマルチマスター¶

デフォルトでは、 BDRはグループ内の各ノードに各テーブルのコピーを1つ保持し、変更はグループ内のすべてのノードに伝播します。

データのコピーはどこにでもあるため、 SELECT はローカルノードにアクセスするだけで済みます。読み取り専用クラスターでは、1 つのノードのパフォーマンスはノードの数に影響されません。したがって、ノードを追加すると、可能な合計SELECTスループットが直線的に増加します。

INSERT、UPDATEおよびDELETE（DML）がローカルで実行される場合、変更はグループ内のすべてのノードに伝播します。 DML適用のオーバーヘッドは元の実行よりも少ないため、複数のノードで純粋な書き込みワークロードを同時に実行する場合、マルチノードクラスターは単一ノードよりも多くのTPSを処理できます。

競合処理には、スループットを低下させるコストがあります。スループットは、アプリケーションが実際に表示する競合の量によって異なります。競合が非常に少ないアプリケーションは、単一のノードよりも優れたパフォーマンスを発揮します。競合の多いアプリケーションは、単一のノードよりもパフォーマンスが低下する場合があります。これらの結果は、マルチマスターテクノロジーと一致しています。彼らはBDRに固有のものではありません。

Eager Replicationは競合を回避できますが、本質的にコストが高くなります。

レプリケーションの遅延が最小限に抑えられるように、変更はすべてのノードに同時に送信されます。ノードを追加するということは、レプリケーションにより多くのCPUを使用することを意味するため、ノードが追加されるたびにピークTPSがわずかに低下します。

ワークロードがすべてのCPUリソースを使用しようとする場合、このリソースはレプリケーションを制約し、レプリケーションの遅延に影響を与える可能性があります。

BDR AlwaysOn¶

AlwaysOn アーキテクチャは、2 つの異なるリージョンの 2 つのグループから構築されています。各グループは HA と IS を提供しますが、一緒に災害復旧 (DR) も提供します。そのため、このアーキテクチャを非常に高可用性の AlwaysOn と呼びます。

テーブルは両方のグループにわたって作成されるため、変更はローカルグループ内のノードだけでなくすべてのノードに適用されます。

1つのノードがメインアプリケーションのターゲットです。他のすべてのノードはシャドウノード（または「読み書きレプリカ」）と呼ばれ、必要に応じて引き継ぐのを待っています。ノードが接続を失った場合、すぐにシャドウノードに切り替えて処理を続行します。グループに障害が発生した場合、他のグループに切り替えることができます。スケーラビリティはこのアーキテクチャの目標ではありません。

主に1つのノードのみに書き込むため、間の競合の可能性はほぼゼロに削減されます。その結果、パフォーマンスへの影響が大幅に削減されます。

CAMOはローカルグループでは積極的なEager Replicationであり、他のグループに関しては怠惰です。

セカンダリアプリケーションはシャドウノードに対して実行される場合がありますが、メインアプリケーションがそのノードの使用を開始すると、これらは削減または中断されます。

将来的には、1つのノードが他のグループのメインレプリケーターとして選択され、クラスターの成長に合わせてレプリケーションのCPUオーバーヘッドが制限され、他のグループへの帯域幅が最小限に抑えられます。

展開¶

BDRは、TPAexecまたはテクニカルサポートによって承認された構成管理アプローチと展開アーキテクチャを使用して、少数の正常な構成の1つで展開されることを目的としています。

手動展開は推奨されておらず、サポートされていない場合があります。

アーキテクチャのTPAexec Architecture User Manual を参照してください。

ログメッセージとドキュメントは現在英語でのみ提供されています。

時計とタイムゾーン¶

BDRは、マルチプルのタイムゾーンのノードで動作するように設計されているため、真にワールドワイドなデータベースクラスターが可能です。個々のサーバーを一致するタイムゾーンで構成する必要はありませんが、 log_timezone = UTC を使用して、人間が判読可能なサーバーログにアクセスして比較できるようにすることをお勧めします。

NTPまたはその他のソリューションを使用してサーバーの時計を同期します。

クロックの同期は、他のいくつかのソリューションと同様に、パフォーマンスにとって重要ではありません。クロックスキューは、オリジンの競合検出に影響を与える可能性がありますが、 BDRは存在するスキューを報告および管理するためのコントロールを提供します。

Column-level conflict detection で説明されているように、

BDRは行バージョンの競合検出も提供します。