Architectural Overview¶
BDRは、メッシュトポロジを使用した疎結合マルチマスターロジカル複製を提供します。つまり、任意のサーバーに書き込むことが可能で、変更は同じBDRグループに属する他のすべてのサーバーに行ごとに直接送信されます。
node diagram¶
デフォルトでは、 BDRは非同期レプリケーションを使用し、ローカルコミット後にのみ同等なに変更を適用します。オプションのeager all node replication機能により、コンセンサスを使用してすべてのノードでコミットできます。
基本アーキテクチャ¶
複数のグループ¶
BDRノードは少なくとも1つのノードグループのメンバであり、最も基本的なアーキテクチャでは、BDRクラスター全体に対して単一のノードグループがあります。
複数のマスター¶
BDRグループに参加している各ノード（データベース）は、他のメンバーから変更を受け取り、ユーザが直接書き込むことができます。
これは、1つのマスターサーバーのみが書き込みを受け入れ、他のすべてのノードがマスタまたは別のスタンバイから複製するスタンバイであるホットスタンバイまたはウォームスタンバイとは異なります。
常にすべてのマスターに手紙を書く必要はありません。ほとんどの場合、1つのマスタにのみ書き込みを指示する構成が頻繁に行われます。ただし、一方向のレプリケーションが必要な場合は、pglogicalの使用がより適切な場合があります。
非同期、デフォルト¶
1つのBDRノードで行われた変更は、ローカルでコミットされるまで他のノードに複製されません。その結果、データは常にすべてのノードで正確に同じではありません。一部のノードには、他のノードにまだ到着していないデータがあります。
PostgreSQLのブロックベースのレプリケーションソリューションも、デフォルトで非同期レプリケーションになります。
BDRでは、マルチプルのマスターがあり、結果としてマルチプルのデータストリームがあるため、synchronous_commitとsynchronous_standby_namesが使用されている場合でも、異なるノード上のデータは異なる場合があります。
メッシュトポロジ¶
BDRは、すべてのノードが他のすべてのノードに接続し、すべてのノードが互いに直接データを交換するメッシュネットワークを中心に構成されています。ノードの追加や削除などの特別な状況を除き、 BDR内でのデータの転送はありません。データは、 BDRクラスターの外部から到着するか、pglogicalまたはネイティブのPostgreSQLロジカルレプリケーションを使用して先に送信されます。
論理複製¶
論理レプリケーションは、レプリケーションID（通常はプライマリキー）に基づいてデータ行とその変更をレプリケートするメソッドです。正確なブロックアドレスとバイト単位の物理的レプリケーションとは対照的に、用語ロジカルを使用します。レプリケーション。インデックスの変更は複製されないため、書き込み増幅が回避され、帯域幅が削減されます。
ソースノードからデータのsnapshotをコピーすることにより、論理レプリケーションが開始されます。それが完了すると、後のコミットがリアルタイムで発生するときに他のノードに送信されます。変更はSQLを再実行せずに複製されるため、書き込まれた正確なデータが迅速かつ正確に複製されます。
ノードは、ソースノードでコミットが行われたオーダーでデータを適用し、単一ノードからの変更に対してトランザクションの一貫性を保証します。異なるノードからの変更は、他のノードとは独立して適用され、変更の迅速なレプリケーションを保証します。
複製されたデータは、安全な場合はバイナリフォームで送信されます。
高可用性¶
各マスタノードは1つ以上のスタンバイノードで保護できるため、ダウンしたノードはすぐに交換して続行できます。各スタンバイノードは、ロジカルスタンバイノードまたは物理的スタンバイノードのいずれかです。
1つ以上のノードが現在利用できない場合でも、現在接続されているノード間でレプリケーションが続行されます。ノードが回復すると、変更を失うことなく、レプリケーションを中断したところからリスタートできます。
ノードは異なるリリースレベルを実行して、通信に必要なプロトコルをネゴシエートできます。その結果、データベースソフトウェアのメジャーバージョンでも、 BDRクラスターはローリングアップグレードを使用できます。
DDLは、デフォルトでノード間で自動的に複製されます。必要に応じて、 DDLの実行をユーザ制御して、アプリケーションのローリングアップグレードを許可できます。
制限¶
BDRは1つのクラスターで最大99個のマスタノードでテストされていますが、現在は最大32個のマスタノードで使用するように設計されています。各マスタノードは、マルチプルの物理的またはロジカルスタンバイノードで保護できます。スタンバイノードの数に特定の制限はありませんが、一般的な使用法では、マスタごとに2〜3個のスタンバイ、マスタごとに通常最大32個のスタンバイを使用します。
BDRは、タイムハードシーケンスを使用する場合、グループから以前に削除（分割/削除）されたノードをカウントせず、1024ノード（マスタノードとロジカルスタンバイの両方をカウント）を超えないことを想定しています。
BDRは、1つのPostgreSQLインスタンスで最大10個のデータベースを異なるBDRノードグループのBDRノードにできるという制限を設けています。 1つのインスタンス内のマルチプルのノード/データベースを同じBDRノードグループのパートにすることはサポートされていません。
アーキテクチャのオプションとパフォーマンス¶
BDRパフォーマンスの特性評価¶
BDRは、さまざまなアーキテクチャで構成できます。各アーキテクチャには、異なるパフォーマンスとスケーラビリティの特性があります。
グループは、2つ以上のノード（サーバー）で構成されるBDRクラスターの基本的な構成要素です。グループ内では、各ノードは専用のルーターとバックアップを備えた異なるAZにあり、即時のスイッチオーバーと高可用性を実現します。各グループには、専用のレプリケーションセットが定義されています。グループがノードを失った場合、既存のノードをグループからコピーすることで簡単に修理/交換できます。
次のアーキテクチャが利用可能です。
マルチマスター/シングルグループ BDR AlwaysOn BDRワールドワイド BDRオートスケール
最も単純なアーキテクチャは、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ワールドワイド¶
このアーキテクチャでは、マルチプルのBDRグループが世界中のマルチプルのリージョンに存在しますが、グループ内のすべてのノードは常に1つのリージョン内にあります。
ボリュームのテーブルが独自のグループ内でのみ複製されるように構成されている場合、ピーク書き込みTPSはグループの数に応じて線形にスケーリングされます。これにより、ジオシャーディングとも呼ばれる入力場所に基づいたシャーディングデータが可能になります。
これにより、このアーキテクチャは、場所がアプリケーションを自然に分割する方法であるIoT、モニタリング、またはその他の大量データ収集アプリケーションでの使用に非常に適しています。ボリュームのデータはそのリージョンを離れないため、リージョン間のレプリケーションによる高い帯域幅コストを回避できるだけでなく、データのプライバシーと管轄に関する強力な法律に従うことができます。
BDRは、このアーキテクチャでマルチノード読み取りクエリを許可します。大規模なマルチノードクエリは、ノード数が増加するにつれて、応答時間の観点から線形にスケーリングします。各クエリーはすべてのサブクラスターの1つのノードで実行されるため、スループットは制限されます。
BDRオートスケール¶
このアーキテクチャでは、グループの配列を使用して並列計算プラットフォームを作成します。
デフォルトでは、すべてのノードにテーブルが作成されます。レンジテーブルパーティションの場合、ユーザはパーティションをグループ全体にストライピングして自動シャーディングを許可するディストリビューションキーを指定できます。たとえば、TimeStamp、CustomerId、WarehouseId。範囲の代わりに個別のキー値も使用でき、リストベースのパーティショニングを効果的にサポートすることに注意してください。
すべてのノードで同一のテーブルは、複製されたテーブルと呼ばれます。グループ間で分割されたテーブルは、分散テーブルまたは分割テーブルと呼ばれます。複製されたテーブルは、他のテーブルに結合できます。分散テーブルは、複製されたテーブル、またはまったく同じデータディストリビューションを共有する他の分散テーブルにのみ結合できます。
分散テーブルは常に完全に均等に分散されているとは限りません。頻繁にアクセスされるシャードがある場合、不均衡なワークロードに対処するためにそのグループにノードを追加できます。
このフォームのシャーディングにより、アプリケーションが直接ルーティングとして知られている適切なグループにトランザクションを直接送信する場合、OLTP書き込みパフォーマンスは線形に拡張できます。このモードでは、Apache Cassandraなどの分散NoSQLシステムと多少似たアーキテクチャを使用できます。自動スケールは、クラスターが拡張または縮小ニーズがあるときに問題を引き起こし、必要に応じて柔軟にスケーリングする機能を制限するため、ハッシュパーティションをサポートしません。
ワークロードがトランザクションを正しいグループに直接送信できない場合、それらを適切なグループ内の任意のノードにルーティングするコーディネーターノードに対して実行します。その後、コーディネーターはプロキシとして機能し、インダイレクタプロキシルーティングを実行します。各グループには、優先書き込みノードと他の1-2個のシャドウノードがあります。読み取りは、デフォルトでシャドウノードに向けられ、残りが優先ノードである場合はpreferredwriteノードに向けられます。
コーディネーターノードはレイテンシを追加し、コーディネーターで費やされる時間の割合が増加するにつれてスケーラビリティを制限できます。小さな読み取り専用要求が多いワークロードではコーディネーター時間が占める割合が高くなりますが、ラージ意思決定支援クエリではコーディネーター時間が占める割合が小さいため、最適なスケーリングを行います。
シャードルーティングには、BDRcatalogテーブル内に保持されているシャード配布メタデータへのアクセスが必要です。コーディネーターノードはこの情報をカタログテーブルに保存するため、直接ローカルアクセスが可能です。シャード配布メタデータは、クライアント側プログラム内またはルーティングミドルウェア内にキャッシュして、これらのコンポーネントから直接ルーティングを実行できるようにすることもできます。
AutoScaleは、このアーキテクチャでマルチノード読み取りクエリを許可します。大きなマルチノードクエリは、ノードの数が増えるにつれて、応答時間の観点から線形にスケーリングします。各クエリーはすべてのサブクラスターの1つのノードで実行されるため、スループットは制限されます。
AutoScaleは、aCoordinatorを使用する場合のマルチノード書き込みトランザクションをまだサポートしていませんが、これらは将来のリリースでサポートされる予定です。今のところ、これらの操作は受け入れられますが、アトミックではありません。マルチノード書き込みトランザクションは、シャードアーキテクチャのスケーラビリティを制限します。
展開¶
BDR3は、TPAexecまたは構成管理アプローチのいずれかと、テクニカルサポートによって承認された展開アーキテクチャを使用して、少数の既知の適切な構成のいずれかに展開することを目的としています。
手動展開は推奨されておらず、サポートされていない場合があります。
アーキテクチャについては、TPAexec Architecture User Manualを参照してください。
現在、ログメッセージと文書は英語でのみ利用可能です。
クロックとタイムゾーン¶
BDRは、マルチプルのタイムゾーンのノードで動作するように設計されており、ほぼ全世界のデータベースクラスタを可能にします。個々のサーバーをマッチングタイムゾーンで構成する必要はありませんが、人間が読めるサーバーログがよりアクセスしやすく比較しやすいようにlog_timezone = UTCを使用することをお勧めします。
サーバークロックは、NTPまたは他のソリューションを使用して同期する必要があります。
クロック同期は、他のソリューションの場合のように、パフォーマンスにとって重要ではありません。クロックスキューはOrigin Conflict Detectionにインパクトを与える可能性がありますが、BDRは存在するスキューをレポートおよび管理するためのコントロールを提供します。 BDRは、Conflict Detectionで説明されているように、行バージョンの競合検出も提供します。
