Architectural Overview¶

BDRは、メッシュトポロジを使用した疎結合マルチマスターロジカル複製を提供します。つまり、任意のサーバーに書き込むことがパート、変更は同じBDRグループに属する他のすべてのサーバーに行ごとに直接送信されます。

デフォルトでは、 BDRは非同期レプリケーションを使用し、ローカルコミット後にのみ同等なに変更を適用します。オプションのeager all node replication機能により、コンセンサスを使用してすべてのノードでコミットできます。

基本アーキテクチャ¶

複数のグループ¶

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

複数のマスター¶

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

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

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

非同期、デフォルト¶

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

メッシュトポロジ¶

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

論理複製¶

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

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

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

複製されたデータは、安全な場合はバイナリフォームで送信されます。

高可用性¶

各マスタノードは1つ以上のスタンバイノードで保護できるため、ダウンしたノードはすぐに交換して続行できます。各スタンバイノードは、ロジカルスタンバイノードまたは物理的スタンバイノードのいずれかです。

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

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

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

制限¶

BDRは、十分マルチプルロジカルハードウェアとネットワーク上で数百のノードを実行できますが、マスタベースの展開では、1つのクラスターで32をスタンバイノードを実行することは一般物理的に推奨されません。スタンバイノードの数ですが、一般的な使用法は、マスタごとに2〜3個のスタンバイにすることです。スタンバイノードはメッシュネットワークに追加の接続を追加しないため、32ノードの推奨事項には含まれません。

BDRには現在、許可されている現在の最大Raft接続であるため、アクティブノードが1000個以下というハードリミットがあります。

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

BDRクラスターの最小推奨ノード数は3です。これは、2つのノードでは、ノードの1つが機能しなくなるとコンセンサスが機能しなくなるためです。

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

BDRパフォーマンスの特性評価¶

BDRは、さまざまなアーキテクチャで構成できます。各アーキテクチャには、異なるパフォーマンスとスケーラビリティの特性があります。

グループは、2つ以上のノード（サーバー）で構成されるBDRグループの基本的な構成要素です。グループ内では、各ノードは専用のルーターとバックアップを備えた異なるAZにあり、即時のスイッチオーバーと高可用性を実現します。各グループには、専用のレプリケーションセットが定義されています。グループがノードを失った場合、既存のノードをグループからコピーすることで簡単に修理/交換できます。

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

次のアーキテクチャが利用可能です。

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

最も単純なアーキテクチャは、1つのグループを持つだけなので、最初に調べてみましょう。

1つのグループ内のBDR MultiMaster¶

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

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

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

競合ハンドリングには、スループットを低下させるコストがかかります。スループットは、アプリケーションが実際に表示する競合の量に依存します。競合が非常に低いアプリケーションは、単一ノードノードもマルチマスターが低下する可能性があります。それらはBDRのファセッタ特性ではありません。

積極的なレプリケーションは競合を回避できますが、本質的にはより高価です。

変更はすべてのノードに同時に送信されるため、レプリケーションラグが最小限に抑えられます。ノードを追加すると、レプリケーションにCPUが使用されるため、新しいノードが追加されるたびにピークTPSがわずかに減少します。

ワークロードがすべてのCPUリソースを使用しようとすると、リソース制約制約が発生し、レプリケーションラグに影響する可能性があります。

BDR AlwaysOn¶

AlwaysOnアーキテクチャは、2つの別々の地域にある2つのグループから構築されます。各グループはHAとISを提供しますが、一緒にディザスターリカバリー（DR）も提供するため、このアーキテクチャをAlwaysOn with Very High Availabilityと呼びます。

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

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

主に1つのノードのみに書き込むため、競合が発生する可能性はほとんどゼロになり、結果としてパフォーマンスへのインパクトは大幅に減少します。

CAMOは、ローカルグループ内での熱心なレプリケーションであり、他のグループに関しては怠laです。

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

将来の機能：1つのノードが他のグループのメインレプリケーターとして選択され、クラスターの成長に伴うレプリケーションのCPUオーバーヘッドが制限され、他のグループへの帯域幅が最小化されます。

展開¶

BDRは、TPAexecまたは構成管理アプローチのいずれか、およびテクニカルサポートによって承認された展開アーキテクチャを使用して、少数の既知の良好な構成のいずれかに展開することを目的としています。

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

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

現在、ログメッセージと文書は英語でのみ利用可能です。

クロックとタイムゾーン¶

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

サーバークロックは、NTPまたは他のソリューションを使用して同期する必要があります。

クロック同期は、他のソリューションの場合のように、パフォーマンスにとって重要ではありません。クロックスキューはOrigin Conflict Detectionにインパクトを与える可能性がありますが、BDRは存在するスキューをレポートおよび管理するためのコントロールを提供します。 BDRは、Conflict Detectionで説明されているように、行バージョンの競合検出も提供します。