postgresqlがトリガーファイルを発見し、それをスレーブからマスターに自分自身を昇格させるとき、実際には何が起こっていますか？
2つのpostgresサーバー（マスター：サーバーA、スレーブ：サーバーB）間でストリーミングレプリケーションを設定しています。トリガーファイルをタッチしてスレーブがマスターに引き継ぐと、実際には内部で何が起こっているのでしょうか。私が不思議に思っていることの1つは、チュートリアルやドキュメントのどこにも誰も言及していないようですが、これが完了した後で以前のスレーブ（現在はマスター）を再起動するとどうなりますか？ .confファイルはまだ古いスレーブの設定を反映しているため（例えば、hot_standby = on）、物事が台無しになりませんか？サーバーを安全に再起動する前に、その.confを更新する必要がありますか？
背景：私の状況では、マスターのHDDを変更する必要があるのではないかと思いました。これは私が計画している方法です：
- スレーブ（サーバーB）へのフェイルオーバー
- マスター（サーバーA）のHDDを変更して再インストールする
- 再インストールしたサーバーAをスレーブとして起動します。
- サーバーAがサーバーBに追いついたら、サーバーAをマスターに戻し、サーバーBを再びスレーブに戻します。
（ちなみに、より良いワークフローへの提案があれば教えてください）
レプリカサーバー（hot_standbyとして実行されているかどうかにかかわらず）は、PostgreSQLが「リカバリモード」と呼ぶもので実行されています。名前が示すように、これは元々、安全でない停止からの回復を実行するために開発されました。この状況では、トランザクションログ（pg_xlogファイル）を見つける方法を定義するrecovery.confファイルを使用し、使用できなくなるまで適用し続けます、その後、リカバリモードを終了して「通常」モードになり、新しいトランザクションログ自体の生成を開始します。リカバリモードを終了すると、recovery.confファイルの名前がrecovery.doneに変更され、その後の再起動で直接通常モードになります。
このプロセスからのレプリケーションスレーブの変更点は次のとおりです。
- トランザクションログデータはログファイルからではなく、マスターサーバーからストリーミングされる場合があります。recovery.confは、
- レプリカは、使用可能なデータがなくなってもリカバリモードを終了せず、トリガーが起動されるまで待機します。
したがって、recovery.confの名前が変更されたため、新しく選択されたマスターを再起動しても、マスターであるというプロパティは保持されます。
ただし、1つの注意点：リカバリが完了し、サーバーがリカバリモードから通常モードに移行すると、「タイムライン」が変更されます。基本的に、この時点でデータベースを分岐しました。1つのバージョンはトランザクションログがどこから来た場合でもトランザクションログが継続する可能性があり、1つのバージョン（新しいバージョン）は回復が完了したばかりのデータベースからのものです。ただし、ログファイルを適用できるのは、同じタイムライン上にあるマスターサーバーからのみです。これが、フェイルオーバーの実行後、単に起動して「追いつく」のではなく、新しいマスターから古いマスターサーバーを再構築する必要がある理由です。
（現在、フェイルオーバーに関する私の経験は限られているため、この上の段落は疑問の余地がありますが、それは私のドキュメントの理解とシステム全体のしくみによるものです）。
また、hot_standbyフラグはonlyを意味します。これは、データベースクラスターが接続を受け入れ、リカバリーモードでも読み取り専用クエリを許可することを意味します。リカバリーしているデータベースの通常の状況ではありませんクラッシュから。サーバーが「通常モード」で実行されると、この設定は無関係になるため、古いスレーブ/新しいマスターにサーバーを設定しても問題ありません。