PostgreSQL 9.1を評価していますが、フェイルオーバーとレプリケーションの詳細に関連する質問はほとんどありません。
テストシナリオはほとんどありません。マスターサーバーと少数のスレーブを備えた最初のサーバー。マスターがクラッシュした場合、スレーブの1人がマスターになります。マスターが通常の状態に戻った後、クラスター内の他のサーバーと同期し（ダウン中に行われたすべての変更を適用）、マスターの役割を要求するか、スレーブになります。
PostgreSQLで見られる問題と現在のシナリオは次のとおりです。
1）マスターサーバーの停止を検出するための組み込みツールが表示されません。pgpoolがそれを処理し、トリガーファイルを作成できることを読みました。また、人々はこれにLinuxのハートビートまたは類似のツールを使用していることも読みました。さて、フェールオーバーを検出して、クラスター内に新しいマスターを割り当てることができます。他のスレーブは、新しいマスターが存在することを理解し、今すぐバックアップする必要がありますか？
2）フェールバック手順がわかりません。マスターとスレーブのホスト構成は異なります。マスターフェイルバックがクラッシュした後、2つのマスターを使用できますか？サーバーはどのように同期しますか？「データフォルダーをサーバーに転送して再起動する」などの手動のソリューションのみを見ました。それでは、ここでの解決策やベストプラクティス、または少なくとも主要な原則は何ですか？
3）クライアント側でサーバーの停止を処理するにはどうすればよいですか？接続を作成するときに、サーバーIPを明示的に指定します。マスター-スレーブ構造を認識し、マスターのみにリクエストを送信し、接続が失われた場合にバックアップサーバーに切り替えるなど、何らかの種類のConnectionManagerを開発する必要がありますか？私は、pgpoolがアプリケーションのエントリポイントとなり、正しい方法で接続を管理できることを読みました。ここではpgpoolのみが解決策ですか？フェールオーバーとフェールバックを適切に処理しますか？
4）手動でデータをコピーし、PostgreSQLインスタンスやその他の手作業で行うべきものを再構成することを避けるためのソリューション（商用）もありますか？だから、全員が同期しているときのクラスター構成のようなもので、誰がマスターであり、すべてがオペレーターの注意なしに自動的に切り替わるのかは明らかですか？
これらのスレッドと記事によると
PostgreSQLでのストリーミングレプリケーションとフェールオーバー
http://denishjpatel.blogspot.com/2010/11/possibility-of-graceful-switchover.html
これらの疑問を解決するための単一の完全自動ソリューションはありません。私は正しいですか？
ありがとう！