使用するPostgresqlレプリケーションソリューション（非同期マルチマスター/ブカルド？）
まず、私はDBAではないので、この質問のいずれかが「オフ」であると思われる場合はご容赦ください。
マッチメイキングのために複数のサーバーの1つに接続するピアツーピアマルチプレーヤーゲーム（クライアント）を作成しました。
現在、ゲームのカスタムマッチメイキングプロセスとPostgreSQL 8.4を実行するサーバーは1つだけです（リノード、サーバー1と呼びましょう）。PostgreSQL8.4（必要に応じて、これを9.1、9.2、9.3にアップグレードします）。
マッチメイキングプロセスは、すべてのSQLステートメントに対してlibpqを非同期で使用します。ステートメントは複雑すぎないため、負荷分散は問題になりません。
マッチメイキングプロセスとPostreSQLを必要に応じて実行するlinode（サーバー2、3、4などと呼びます）を追加する予定です。課題は、すべてのクライアントに高可用性を求めていることです。サーバー1に到達できない場合は、代わりにサーバー2を使用して、すべて同じデータにアクセスできます。
当初の計画では、すべてのサーバーをサーバー1のデータベースに接続し、libpqを介してSQLステートメントを非同期に送信していました。問題は、サーバー1が一時的にオフラインになるか、到達できない場合、他のすべてのサーバーで障害が発生することです。
私が想像できる最も単純なソリューションは、各サーバーがデータベースを完全にミラーリングすることです。サーバー1がダウンした場合、クライアントはサーバー2に接続し、サーバー2は自身のデータベースに読み書きし、サーバー3と4への変更を即座に複製し、サーバー1がオンラインに戻ると複製します。
この方法では、すべてのサーバーがデータベースの「ミラーリングされた」コピー全体を保持します。
PostgreSQL 9.3のレプリケーションに関するドキュメント の紹介セクションを読んだ後、このソリューションを実装する方法は非同期マルチマスターレプリケーションになるようです。 （ブカルドはここで唯一の選択肢ですか？）
非同期レプリケーションで気になるのはSQL挿入です。新しいクライアントが初めて再生するときに、プレーヤーデータベースエントリが作成されます。サーバー2、3、および4がオンラインで、サーバー1がオフラインの場合、2が新しいプレーヤー行を挿入すると、1、3、または4で問題が発生しますか？ （1がオンラインに戻ってすぐに別のプレーヤーの行を挿入しようとしていると想像してください。）
非同期マルチマスターは、上記のシナリオに進むための正しい方法ですか？
または、私が見落としているより簡単または簡単な解決策はありますか？おそらく、ミドルウェアを必要とせず、PostgreSQL 9.3の組み込みレプリケーションを使用するだけでしょうか？
DBAではない場合、つまり、レプリケーション、フェイルオーバー、トランザクション分離の微妙な問題などの経験がない場合は、可能であればnotマルチマスターを使用してください。
PostgreSQLにはマルチマスタークラスタリングはなく、サードパーティのアドオンを介したマルチマスターレプリケーションのみです。これらのアドオンはパフォーマンスに大きな影響を与えますが、さらに重要なことに、ノード間のロックとトランザクションの分離を処理しません。異なるノードでの並行トランザクションは、異なるデータを参照したり、同じ行を変更したりすることができます。
率直に言って、マルチマスタークラスタリングは、それを利用できる製品であってもかなり圧倒されます。パフォーマンスはかなり悪く、スケーリングも悪くなる傾向があります。これは製品の欠陥ではなく、MMのクラスタリングがhardであり、正しいorを選択するのがかなり早いということです。
個人的には、2つの大きなノードを使用することをお勧めします。 1つのノードでストリーミングレプリカを実行し、もう1つのノードでマスターとして実行します。一方がダウンした場合は、もう一方にフェイルオーバーします。容量を追加する前に、アプリとクエリを適切に調整してください。
この件に関する情報も探していました。次のオープンソースプロジェクトに出くわしました。
http://2ndquadrant.com/en/resources/bdr/
また、パフォーマンスセクションで利用可能なさまざまなソリューションのベンチマークも提供します。