Architectural Overview¶

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

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

基本アーキテクチャ¶

複数のグループ¶

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

マルチプルマスター¶

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ノードの推奨には含まれません。

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

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

BDRクラスターの推奨されるノードの最小数は3です。2つのノードでは、いずれかのノードが動作を停止するとコンセンサスが動作を停止するためです。

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

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

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

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

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はローカルグループ内の熱心なレプリケーションであり、他のグループに関しては怠惰です。

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

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

展開¶

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

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

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

ログメッセージと文書は現在英語でのみ提供されています。

時計とタイムゾーン¶

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

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

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

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

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