すみません、recovery.confを壊しました

PostgreSQLでは、2005年にリリースされた非常に古いバージョン8.0から、特定の時点に復元するために特別な構成ファイルrecovery.confが使用されていました。 その後、同じファイルがスタンバイモードとストリーミングレプリケーションに使用されるようになりました。

ただし、PostgreSQL 12の次のリリース以降、recovery.confは機能しなくなりました。破損しました。
しかし、なぜですか？

Recovery.confには1つの機能がありました。それは、DBMSの開始時にのみ読み取られました。 また、1年に1回未満で必要なポイントインタイムリカバリを調整できる場合は、データベース全体を再起動してアップストリームレプリケーションサーバーのアドレスを変更する必要があります。 この制限を回避するために、L3ルーティングの使用、複製スキームのカスケード（すべてがすべてではなく、少なくとも一部のみ）、さらには（ 実稼働環境では見られない場合でも） walbouncerなど、さまざまな倒錯の方法を見ました 。

レプリカの次のスケジュールされた再起動後、レプリケーションパラメータを変更する必要があるため、それを選択することにしましたが、SIGHUPでprimary_conninfoを再読み込みするようにPostgreSQLに教えるのに費用はかかりますか？ すべてがひどく判明しました。 原則として、起動プロセスで変更する必要があるのは1つの変数のみで、そこからWalReceiverの再起動を要求します。それで、複製は新しいアドレスで正しく続行されます。 これを正しく実装することは残っています。 数週間後、SIGHUPシグナルでrecovery.confを再読み込みすることでパッチを終了しましたが、そのパッチは既存のデータベースの動作を破壊しませんでした。

そして勇気を持って、 彼をPostgreSQL開発者のメーリングリストに送りました。 Michael Paquierがかなり迅速に答えたもの：

それらのいくつかを再読み込み可能にする前に、それらを最初にGUCに切り替えて、パッチのようにパラメーターのSIGHUP処理を再発明しないでみましょう。

おっと、検索エンジンに間違った質問をしていることがわかりました。 問題は、recovery.confの再読み取りではなく、別のrecovery.confから他のすべてのDBMSパラメーターに使用されるGUCインフラストラクチャ（グランド統合構成）へのパラメーターの変換に関するものでした。 つまり、間違いなく、このようなパッチは必要ありません。これは望ましくありません。 最初に、これらすべての設定をrecovery.confから標準設定インフラストラクチャに転送しましょう。

この悲観的なニュースで、私は燃えて考えました：「でも移しましょう！」。 正しい検索クエリでアーカイブされたディスカッションを読み、 設定の転送に関する最後のディスカッションを開きました （リンクはMichael Paquierの回答で親切に提供されました。迅速な回答だけでなく、別途感謝します）。 そのとき、2018年5月に、パッチは1年以上放棄されました。 それでは、ここから始めましょう。 それとも「続ける」と言う方が正しいでしょうか？ エンターテインメントプランによると：

1. パッチの最新の公開バージョンへの変更を読んでリストする
2. パッチの変更を解析し、必要なものをコードベースの現在のバージョンに転送します
3. ドキュメント内のrecovery.confおよびそのパラメータへのすべての参照を修正
4. 修理テスト
5. メーリングリストに新しいパッチを送信します
6. フィードバックを得る
7. 希望に応じて何かを修正し、パラグラフ5に戻る
8. パッチを再度拒否することを拒否する（1年半）

アクションプランのように聞こえますか？ さて、ここでそれに沿って進みます！

どのくらいの時間、短い間、私は5番を指し示し、2018年6月21日に新しいディスカッションスレッドで新しいバージョンのパッチを公開しました 。 その後、バスカヴィルの魚の冷たく沈黙の圧迫的な沈黙の中で3ヶ月。 9月末、コア開発者の1人であるコミット権を持つPeter Eisentrautは、突然パッチに関心を示しました。 編集を数回繰り返した後、私は静かに数日間、ブダペストを散歩して観光するために立ち去りましたが、ピーター・アイゼントラウトからの落胆的な手紙が届きました。

パッチを調べて、いくつかの小さな改良を行いました。 また、ドキュメントをより広範囲に更新しました。 添付のパッチは私にコミット可能です。

つまり、Peter Eisentrautは彼の裁量でいくつかのささいなことを修正し、ドキュメントを更新し、recovery-config.sgmlセクションを完全に焼き付け、この形式でパッチはすでに受け入れられると考えています。 ああ、幸運にもパッチが一般的にコミットの準備が整った状態に達したとしても、それはpostgresql 13でのみ起こると思いました。

そして数日後、つまりこの2018年11月25日に、ピーター・アイゼントラウトは本当にこのパッチを受け入れます ：

recovery.conf設定がpostgresql.conf（または他のGUCソース）で設定されるようになりました。 現在、影響を受ける設定はすべてPGC_POSTMASTERです。 これは、将来のケースバイケースで改善される可能性があります。
回復は、ファイルrecovery.signalによって開始されるようになりました。 スタンバイモードは、ファイルstandby.signalによって開始されます。 standby_mode設定はなくなりました。 recovery.confファイルが見つかった場合、エラーが発行されます。
移動の一部として、trigger_file設定の名前がPromote_trigger_fileに変更されました。
ドキュメントの章「リカバリ構成」が「サーバー構成」に統合されました。
pg_basebackup -Rがpostgresql.auto.confに設定を追加し、standby.signalファイルを作成するようになりました。
著者：藤井正夫<masao（dot）fujii（at）gmail（dot）com>
作成者：Simon Riggs <simon（at）2ndquadrant（dot）com>
著者：Abhijit Menon-Sen <ams（at）2ndquadrant（dot）com>
作成者：Sergei Kornilov <sk（at）zsrv（dot）org>

2週間が経過し、このコミットはロールバックされていません。 すごい そして、彼らは行きさえしないようです。 すごい。 特に4月のpostgresql 12の機能フリーズリリースまでにはまだ少し時間がありますので、コミュニティが再びあらゆる方向に動作を変更することを決定するかどうかは不明です。 ただし、recovery.confの数はまだ増えていないようです。

それで、何が変わったのか

何よりもまず、recovery.confファイルが見つかった場合、DBMSは起動を拒否します。これは、多くの古い命令の1つを使用しているユーザーがデータベースがこのファイルの構成を無視する理由に驚かないようにするためです。

古いstandby_mode設定はなくなりました。 これで、リカバリモードを有効にするためのrecovery.confの存在自体が、2つのファイル（任意のコンテンツ、通常は空）に置き換えられました。

• $ PGDATA / recovery.signal-イデオロギーの後継者standby_mode = off。アーカイブからの復元は、構成ファイルで指定されたポイントまで実行されます。
• $ PGDATA / standby.signal-それぞれ、standby_mode = on。 このファイルはすべてのレプリカに表示されます。

データベースの起動プロセスで両方のファイルが見つかった場合は、スタンバイモードにあると見なします。

明確にするために、パラメータの変更をプレートに減らす場合：

古いrecovery.conf	PostgreSQL 12以降postgresql.conf
primary_conninfo	primary_conninfo
primary_slot_name	primary_slot_name
trigger_file	Promo_trigger_file
recovery_min_apply_delay	recovery_min_apply_delay
recovery_target	recovery_target
recovery_target_name	recovery_target_name
recovery_target_time	recovery_target_time
recovery_target_xid	recovery_target_xid
recovery_target_lsn	recovery_target_lsn
recovery_target_inclusive	recovery_target_inclusive
recovery_target_timeline	recovery_target_timeline
recovery_target_action	recovery_target_action
restore_command	restore_command
archive_cleanup_command	archive_cleanup_command
recovery_end_command	recovery_end_command

何も変更されていないことが少しわかります。 現時点では（promote_trigger_fileのpromote_プレフィックスを除いて）、すべての新しいパラメーターは古いパラメーターとまったく同じ名前が付けられ、同じ可能な値を取ります。 実際には、リカバリターゲットの設定に関してはまだ変更があります。 以前に誰かがこれを使用したかどうかはわかりませんが、これは文書化された動作であり、複数のrecovery_target、recovery_target_lsn、recovery_target_name、recovery_target_timeまたはrecovery_target_xidを同時に指定できました。 例えば

recovery_target_lsn = '1/1D9FEA00' recovery_target_xid = '5238954' 

recovery.confの最後の行は、実際にはリカバリに使用されました。 これはもうできません。回復の目標は最大1つで示す必要があります。 ただし、GUCインフラストラクチャのロジックにより、同じ名前のパラメーターを何度も指定できます。

 recovery_target_lsn = '1/1D9FEA00' recovery_target_lsn = '1/16AC7D0' 

これは受け入れられ、最後に指定された設定値に復元されます。

そして、一般的に、これはPostgreSQLの外部から見える変更について言う必要があるすべてです。 pg_basebackup -R（--write-recovery-conf）はそのままで、意図したとおりに動作しますが、recovery.confの代わりにpostgresql.auto.confにパラメーターを追加し、standby.signalファイルを作成します。

残念ながら、これらが現在目に見えるすべての変更であると言ったとき、これはまさに私が言っていることです。 新しいパラメーターはすべてPGC_POSTMASTERとして設定されます。つまり、PostgreSQLの起動時にのみ変更できます。 既に述べたように、これは開発者コミュニティの一部の要件でした。最初にすべての設定を転送してから、実行中のデータベースで変更できるかどうかを確認します。 そのため、古い動作が既に壊れていて、良い方向への変更がまだもたらされていないとき、PostgreSQLは素晴らしい開発段階にあります。

primary_conninfoとprimary_slot_nameをその場で変更できるようにするパッチをすでに公開しています。 何が起こるか見てみましょう。

すみません、recovery.confを壊しました

UPD 2019年4月7日

機能フリーズバージョン12の最終日までに、要約できます。 レプリケーション設定の変更はリリースに含まれていませんでした。 もちろん、これも奇妙な話です。 むかしむかし、私が基礎として取ったSimon Riggsパッチには、接続設定を変更するときにwalreceiverを再起動するための編集がすでに含まれていました。 ドキュメントとテストを補足する別のパッチでそれらを選択しました。 6回のパッチ更新と数か月の議論の後、walreceiverを再起動すると、データベースはrestore_commandからのファイルの復元に切り替えようとするという明らかな事実が現れます。 なんらかの理由でwalreceiverをシャットダウンすることでトリガーされる、非常に単純なステートマシンの動作。 しかし、これは「望ましくないもの」であることがわかりました。 さて、あなたが言うことができない前に？ なんとかやり直しましたが、カレンダーにはすでにバージョン12の最終commitfestがあり、誰もここを見ませんでした。 一般に、これは簡単なことではなく、PostgreSQLのパッチはそうです。 しかし、私は人々のリストに自分を含めるすべての権利を持っています。そのおかげで、 最も壮大で未完成の未完成のREINDEX CONCURRENTLYがバージョン12 に含まれていました！

最後に言及する価値があるのは、多くの設定がオンザフライで変更する機会があることです：archive_cleanup_command、promote_trigger_file、recovery_end_command、recovery_min_apply_delay