Creating and joining PGD groups#
PGDグループの作成と参加#
- PGDの場合、すべてのノードは他のすべてのノードに接続する必要があります。構成を簡単にするために、新しいノードが参加すると、既存のすべてのノードがそれに接続するように構成します。このため、最初に作成したPGDノードを含むすべてのノードは、
他のノードが接続するために使用できるもの。この接続文字列は、データソース名DSNと呼ばれることがあります。
両方の形式の接続文字列がサポートされています。したがって、
host=myhost port=5432 dbname=mydb のようなキー-値形式、または
postgresql://myhost:5432/mydb のようなURI形式を使用できます。
SQLファンクション bdr.create_node_group()
ローカルノードからPGDグループを作成します。これにより、そのノードでPGDがアクティブになり、他のノードがその時点で1つのノードのみで構成されるPGDグループに参加できるようになります。作成時に、このノードへの接続に使用する他のノードの接続文字列を指定する必要があります。
- ノードグループが作成されると、それ以降のすべてのノードは、
bdr.join_node_group() を使用してPGDグループに参加できます。
ファンクション。
または、コマンドラインユーティリティ bdr_init_physical を使用して、
pg_basebackup を使用して新しいノードを作成します。 pg_basebackup
を使用する場合、
bdr_init_physicalユーティリティはオプションでターゲットデータベースのみのベースバックアップを指定できます。以前の動作は、データベースクラスター全体をバックアップすることでした。このユーティリティを使用すると、アクティビティがより速く完了し、不要なデータベースを除外するため、使用する領域が少なくなります。ターゲットデータベースのみを指定した場合、除外されたデータベースは新しいノードでクリーンアップおよび削除されます。
新しいPGDノードが既存のPGDグループに参加するか、ノードが上流ピアをサブスクライブする場合、レプリケーションを開始する前に、システムは既存のデータをピアノードからローカルノードにコピーする必要があります。このコピーは、ローカルデータとリモートデータが同一に始まるように、注意深く調整する必要があります。 pg_dumpを自分自身で使用するだけでは十分ではありません。 BDR拡張機能は、この初期コピーを作成するためのビルトイン機能を提供します。
参加プロセス中に、 BDR拡張機能は提供されたソースノードをベースとして使用して既存のデータを同期し、 PGDグループのメッシュトポロジで自分自身を確立するために必要なすべてのメタデータ情報を作成します。この初期コピー中にソースと新しいノード間の接続が切断された場合、参加プロセスを最初からリスタートします。
クラスターに参加するノードには、PGDグループのデータベースに既に存在するスキーマまたはデータが含まれていない必要があります。新しく参加するデータベースは、 BDR拡張機能を除き空であることをお勧めします。ただし、必要なデータベースユーザーとロールがすべて作成されていることが重要です。
オプションで、 bdr.join_node_group のsynchronize_structure
パラメーターを使用して、スキーマの同期をスキップできます。
ファンクション。この場合、スキーマは新しく参加するノードに既に存在する必要があります。
最適な接続論理的に近く、理想的には低遅延、高帯域幅を持つソースノードを、参加するソースノードとして選択することをお勧めします。そうすることで、結合が完了するまでに必要な時間が短縮されます。
Raftコンセンサスアルゴリズムを使用して参加手順を調整します。これには、既存のノードのほとんどがオンラインで到達可能である必要があります。
論理結合プロシージャ bdr.join_node_group を使用します
ファンクションは、COPY
操作を実行してデータ同期を実行し、マルチプルのライターパラレル適用が有効になっている場合を使用します。
ノード参加は、参加にかかる時間の大部分で他のノード参加と同時に実行できます。ただし、一度に1つのレギュラーノードのみがPROMOTEまたはPROMOTINGの状態になることができます。他のすべてのノードが起動して実行されている場合、これらの状態は通常かなり短いです。それ以外の場合、結合はこの段階でシリアル化されます。サブスクライバ専用ノードはこのルールの例外であり、それらは同時にPROMOTEおよびPROMOTING状態になることもできるため、それらの参加プロセスは完全にコンカレントです。
参加プロセスはソースとして1つのノードのみを使用するため、ノードの大部分が利用可能な場合、ノードがダウンしているときに実行できます。このアプローチでは、論理結合を実行するときに複雑さが発生する可能性があります。論理結合中に、ソースノードからコピーされた行のコミットタイムスタンプは、ソースノードの最新のコミットタイムスタンプに設定されます。これより前のコミットタイムスタンプを持つノードでコミットされた変更は、ノードがダウンしているか、大幅な遅延があるため、他のノードからの変更と競合する可能性があります。この場合、新しく参加したノードは他のノードとは異なる方法で解決され、発散が発生する可能性があります。その結果、ノード間に重大なレプリケーションラグが存在する場合は、ノード参加を実行しないことをお勧めします。これが必要に応じて、すべてのノードが利用可能になって追いついた後、新しく参加したノードでLiveCompareを実行してデータの相違を修正します。
pg_dump
は、ソースノードに同時のDDLアクティビティがある場合、キャッシュルックアップの失敗が原因で失敗する場合があります。
bdr.join_node_group は内部でpg_dumpを使用するため、ソースノードに同時のDDLアクティビティがある場合、失敗する可能性があります。その場合、結合を再試行すると機能します。