PostgreSQLのフェイルオーバーとレプリケーション
私はPostgreSQL 9.1を評価していますが、フェイルオーバーとレプリケーションの詳細に関していくつか質問があります。
テストシナリオはほとんどありません。マスターサーバーと少数のスレーブを持つ最初の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
これらの質問を解決する単一の完全自動ソリューションはありません。私は正しいですか？
ありがとう！
- スレーブは新しいマスターを理解しません。手動で行う必要があります。
はい、それらは異なり、古いマスター用に新しいものを作成する必要があります。ただし、古いスタンバイは引き続きマスターとして機能しますが、そのノードにmax_wal_sendersを設定する必要があります。フェイルオーバー後に新しいマスターのpg_hba.confも設定する必要があります。フェイルオーバー後（ノードが役割master-> slave slave-> masterを変更する場合）、recovery.confファイルで設定した新しいスタンバイフォルダーのデータディレクトリに新しいwalファイルを転送する必要があります。または単にrsyncを使用できます。
pgbouncerを使用できるかもしれません。この方法では、pgbouncerサーバーのアドレスを新しいマスターに変更するだけです。
EnterpriseDBにはいくつかの商用ツールがあります。確認できるかもしれません。
そして最後に、あなたは正しいです。これらの質問を解決する単一の完全自動ソリューションはありません。