Proxies, Raft, and Raft subgroups#
PGDは、トップレベルグループがPGDインストール内のすべてのデータノードにまたがるRaftモデルを使用してメタデータを管理します。 Raftリーダーは、トップレベルグループによって選出され、トップレベルグループの状態をグループ内の他のすべてのノードに伝播します。
トップレベルグループの特定の操作では、Raftリーダーを確立して接続することが重要です。これらの操作の例には、ノードの追加と削除、 ローカルシーケンスのgallocシーケンスへの変換 シーケンスのレンジの割り当てが含まれます。
また、トップレベルグループのノードの絶対大多数それらの半分と1つが相互に到達できる必要があることも意味します。したがって、5つのノードを持つトップレベルグループでは、Raftリーダーを確立するには、少なくとも3つのノードが相互に到達可能である必要があります。
プロキシルーティング#
同じくRaftを使用する機能の1つがプロキシルーティングです。プロキシルーティングでは、プロキシがノードのグループ内のデータノードへの書き込みを調整できる必要があります。このデータノードは書き込みリーダーです。書き込みリーダーがオフラインになった場合、プロキシはデータノードによって選択された新しい書き込みリーダーに切り替えて、接続されたアプリケーションの継続性を維持できる必要があります。
PGD 5ではノードグループごとにプロキシルーティングを構成できますが、推奨される構成は グローバル および ローカル ルーティングです。
グローバルルーティング#
グローバルルーティングは、トップレベルグループを使用してプロキシルーティングを管理します。グループ内のすべての書き込み可能なデータノード監視またはサブスクライブ専用ノードではないは、すべてのプロキシの書き込みリーダーになる資格があります。トップレベルグループ内のプロキシへの接続は、トップレベルグループ内のデータノードにルーティングされます。
グローバルルーティングでは、トップレベルグループ全体に対して書き込みリーダーが1つだけあります。
ローカルルーティング#
ローカルルーティングは、多くの場合場所にマッピングされるサブグループを使用して、サブグループ内のプロキシルーティングを管理します。ローカルルーティングは、書き込みを地理的に分離するために使用されることがよくあります。トップレベルのコンセンサスが失われた場合でも、ルーティングを継続することが重要です。
これは、PGDを使用すると、トップレベルのコンセンサスが失われた場合でも、クエリと非同期データ操作DMLが機能するためです。しかし、グローバルルーティングの場合と同様に、トップレベルコンセンサスを使用することは、そのコンセンサスが失われた場合に新しい書き込みリーダーを選択できないことを意味します。ローカルグループは、独立したコンセンサスメカニズムとその複雑性を追加せずに、トップレベルのコンセンサスに依存することはできません。
PGD 5では、この問題にエレガントに対処するためにサブグループRaftサポートを導入しました。サブグループRaftのサポートにより、PGDトップレベルグループのサブグループは、必要なリーダーを独立して選択できます。彼らは、他のサブグループまたはトップレベルのRaftコンセンサスから独立して書き込みリーダーを選択できる委任されたRaftグループを形成することによりこれを行います。サブグループ内のプロキシへの接続は、サブグループ内のデータノードにルーティングされます。
ローカルルーティングでは、各サブグループに書き込みリーダーがあります。
詳細情報#
Raft subgroups and TPA は、 Trusted Postgres Architectで展開するときにPGDでRaftサブグループを有効にする方法を示します。
Working with Raft subgroups and PGD CLI は、 PGD CLIがRaftサブグループの存在とステータスをレポートする方法を示します。
Migrating to Raft subgroups は、既存のインストールを移行し、TPAを使用せずにRaftサブグループを有効にするガイドです。
Raft elections in depth は、Raftを使用して書き込みリーダーが選択される方法を詳細に調べます。