1.トリガーファイルを使用します。
レプリケーションを構成するためのマニュアルには、recovery.confで、trigger_fileパラメーターを指定できる（特に指定する必要がある）と書かれています。 ここではすべてが簡単です。レプリカでこのパラメーターで指定されたファイルを作成するとすぐに、PostgreSQLはリカバリプロセス（この場合はレプリケーション）を中断し、新しいタイムラインを開きます。
これは、トリガーファイルの作成後、バイナリログカウンターの位置が順番に（たとえば-000000010000000000000043から000000010000000000000044に）変化するのではなく、新しい時代に-（0000000 2 0000000000000043に）変化することを意味します。
幸いなことに、この方法では再起動は必要ありません。すべてがその場で行われます。 ダウンタイムは発生せず（クライアントの設定を変更する時間は考慮されません）、すべての接続が保存されます-PostgreSQLはwalreceiverプロセスに勝ち、記録に先送りします。
悪いニュースは、マスターサーバーとレプリカサーバーが2台しかない場合、この方法が適していることです。 クラスターが3つ以上のマシンで構成されている場合-他のレプリカをリロードせずにこのノードを新しいマスターにすることはできません-別のレプリカを新しいマスターにバインドしようとすると、PostgreSQLは常に次のように言います：
FATAL: timeline 2 of the primary does not match recovery target timeline 1
履歴ファイル（新しいタイムラインへの移行ポイントを保存する-このファイルは回復プロセスが完了するたびに作成される）をスリップするあらゆる種類の試みも失敗しました。 一般に、公式のMailListの参加者は同じ視点に準拠します-このアプローチでは、他のレプリカを再作成する必要があります（9.0の場合-pg_start_backup / pg_stop_backupおよびrsyncを使用し、9.1の場合-pg_basebackupユーティリティを使用します）。
2. recovery.confの削除
何らかの理由で、マニュアルの2番目の方法の説明を見つけることができませんでした（たぶんそこにあり、十分に注意していなかった-私は議論しません）。 あなたはそれが単純で、論理的で、明らかに信頼性があることに同意すると思います（少なくとも-繰り返し実験の過程で何も完全に破ることができませんでした）：
1.クラスター全体から、最新のレプリカを見つける必要があります。 各ホストで何かをすることでコンソールからこれを行うことができます：
# ps aux|grep postg|grep rec
postgres 143 0.0 13.2 8692004 6533448 ? Ss Feb06 3:58 postgres: startup process recovering 00000001000001E500000054
postgres 2683 0.0 0.0 8699452 4044 ? Ss Feb09 0:33 postgres: wal receiver process streaming 1E5/542F9970
マスターのmet石がまだ落ちていないが、分単位でそれが予想される場合は、操作中にバイナリログの位置が変わらないように、事前にマスターノードを配置することをお勧めします。
2.選択したレプリカで、ノードがマスターになるようにpostgresql.confを変更します（次のパラメーターはレプリケーション構成マニュアルから取得されます。この場合、値はもちろん異なる場合があります）。
wal_level = hot_standby
max_wal_senders = 5
wal_keep_segments = 32
archive_mode = on
archive_command = 'cp %p /path_to/archive/%f'
3. pg_hba.confを編集します。
host replication postgres 192.168.100.3/32 trust
4.新しいウィザードでrecovery.confを削除します
5.新しいマスターでPostgreSQLを再起動します。
6.他のレプリカでrecovery.confを編集し（新しいウィザードを指定）、再起動を実行します。
このような簡単な方法で、バイナリログの位置を失うことなくレプリカをマスターに変えることができます。 明らかな欠点-クラスター全体を再起動する必要があります（古いマスターから新しいマスターにIPアドレスを転送する機会がある場合は、レプリカを再起動する必要はありません）。
何らかの理由でレプリカを新しいマスター、つまり最新ではないbin-log位置にしたい場合は、まず最新のレプリカをマスターとして指定する必要があります（ランダム接続からレコードへのクローズを推奨します）。最後にマスターを作成し、その後でのみ、上記で説明したすべての操作を実行します（つまり、実際にはマスターを2回割り当てます。最初は1つのレプリカのみに、次に他の全員に割り当てます）。
一般的に、実験中に見つけた唯一の問題のある場所は、レプリカの一部が遅れて、新しいウィザードが必要なXLOGファイルを必要としなくなったときです。 私は以前の投稿でこれに対処する方法を教えました-アーカイブ中にバイナリログをバックアップサーバーに送信する場合にのみ、この問題は重大とは言えません。