pgpool-IIによる複数のマスターデータベースの設定
Pgpoolのマニュアルにも、この問題の解決策はありませんでした。
Pgpool-IIで複数のマスターpostgresqlデータベースを構成するにはどうすればよいですか？追加の要件は、ストリーミングレプリケーションを使用して、各マスターに独自のスレーブセットがあることです。複数のマスターの理由は、各マスターが大きなデータセットのパーティションを保持するためです。
これは、パーティション化された大きなデータセット（たとえば、約1億人のユーザー、そのアカウント情報、およびそれらのアカウントに関する追加情報）です。サイロ化されています。データモデルは、サイロが互いに対話する必要がないように設計されています。
ヘルプとガイダンスは大歓迎です。
最初の決定は、サイロをアプリケーションレイヤー、またはデータベースレイヤーのどこに分割するかです。アプリケーションがサイロを追跡する場合は、サイロごとに異なるポートで個々のpgbouncerまたはpgpoolサーバーを実行できます。
アプリケーションがサイロ化がどのように行われるかを知ったり処理したりする必要がない場合は、plproxyのようなものが不思議に機能します。基本的に、1つ以上のplproxyサーバーがあり、すべてのクエリ/データを、あらかじめ決められたモジュロ数学またはそれを分解するための他の方法に基づいて配布します。アプリは、そのクエリでplproxyサーバーを呼び出すだけで、plproxyサーバーは、サイロ化のロジックが存在します。
各メソッドには、プラスとマイナスがあります。アプリレイヤーにあることの良い点は、データベースレイヤーがかなりシンプルであることです。マスター/スレーブペアの束だけです。新しいサイロを追加する場合は、アプリで構成ファイルを編集するだけで、オンラインになります。不利な点は、データにアクセスするすべてのアプリがサイロを認識する必要があることなどです。
Plproxyの利点は、アプリがサイロ化されたことを知らないことです。かなり単純なSOAPタイプのインターフェイスを記述してplproxyサーバーと通信する場合、書き込みするすべてのアプリはその単一のインターフェイスを使用でき、どのサイロが何をするかを通知される必要はありません。 dbレイヤーに移動しました。ファーム構造への変更には、dbレベルでの作業が必要です。また、plproxyは、基本的にすべてのデータベース作業を事前に関数にラップすることで機能します。別のテーブルに結合されたテーブルからデータを選択する場合は、それを行うための関数を作成し、その関数をplproxyマシンで呼び出す方法です。最初は非常に複雑に見えますが、実際にはそれほど難しくはなく、dbサーバーでランダムなSQLを投げるのとはまったく異なります。