web-dev-qa-db-ja.com

WALベースの復元後にポストマスタープロセスが（ときどき）管理できなくなるのはなぜですか？

TL; DR：WALベースのバックアップからデータディレクトリを復元した直後にPostgresを起動すると、停止できない、使用できないpostmasterが生成されます。なぜですか？

コンテキスト：

CentOS 6では、PGDGパッケージを使用してpostgresql 8.4を実行します。開発者のテスト環境で使用するスクリプトがあり、本番サーバーのデータディレクトリの夜間バックアップを復元します（pg_start_backupとpg_stop_backupの呼び出しの間に作成されます）。スクリプトはファイルを解凍し、restore_commandを使用して、本番環境でバックアップがとられたときに生成されたWALを再適用します。

通常は正常に機能し、pg_dump 'されたファイルのSQLベースの復元より数百倍速く復元されます。

問題：

場合によっては、データディレクトリを解凍した後、スクリプトが/etc/init.d/postgresql start（/etc/init.d/postgresql-8.4へのシンボリックリンクです。これにより、最終的に9. *にアップグレードするときの予測可能なinitスクリプトになります）を実行してpostgresを開始します。次のように「OK」と報告されます。正しく起動しました。その後、WALは復元されません。 recovery.doneファイルが表示されるまで無期限にハングします。

私が試したこと：

無期限のハング中に/etc/init.d/postgresql statusを実行すると、initスクリプトがdead but pid file existsを報告します。

次に、ps -ef | grep postを実行しました。奇妙なことに、postmasterプロセスやアーカイバーなどが実行されていました。すべての呼び出しパラメーターが正しかった（正しいdatadirなど）。

psqlを実行したところ、実行中のポストマスターとinited postgres DBが検出されましたが、メインDBは検出されませんでした。

次に、データディレクトリの権限を確認しましたが、すべて問題ありませんでした。

/etc/init.d/postgresql stopを実行すると「OK」と報告され、アーカイバー/ウォッチャープロセスが強制終了されましたが、ポストマスターは実行されたままでした。

killall -r '*.postmaster*.'を試したときも同じことが起こりました。

スタックしたWALリストアを再開するために機能したのは、killall -s 3 -r '.*postmaster.*'（信号3はSIGQUIT）と/etc/init.d/postgresql startだけでした。

管理不可能な状態のときにpg_startup.logとpg_logの毎日のファイルを確認しましたが、すべて問題ありませんでした。 pg_startup.logは、正常な開始を最後のエントリとして登録しました。

考えられる原因：

いくつかの（私はマイナーだと思う）事柄は私たちの設定に関して非標準です。

  • 前に言ったように、私たちのinitスクリプトは/etc/init.d/postgresqlのバージョンに依存しないスクリプトにシンボリックリンクされています。これは私たちが望む場所を指します。現在、それは/etc/init.d/postgresql-8.4を指しています。

  • 私たちのpostgresql.confファイルは/etc/（postmasterユーザーの所有者とグループと共に）に存在し、データディレクトリへのシンボリックリンクを持っています。 WAL復元スクリプトは、postgresを開始する前に、シンボリックリンクが確実に再作成されるようにします。

  • 最近、インフラストラクチャをPostgresql 8.4.11から8.4.12にアップグレードしました。新しいバージョンの安定性をテストしています。私たちの運用サーバーは8.4.11を実行しています。ただし、pg_dumpを介してデータをプルし、スクラブしてから、別の場所でWAL復元用に「パッケージ化」するため、互換性のないバージョンのPostgresでWALを復元しません。

質問：

なぜこれを行うのですか？以下にリストされている考えられる原因の1つが原因である可能性がありますか？

postgresqlbackuprestorelogslog-shipping
3
Zac B

一般に、この種の問題が発生している場合は、pgsql-bugsリストで取り上げることが最善の場合があります。そこにいる人々は、どのような情報を収集して、この不正行為の範囲が何かを判断し、修正する手助けをするのに役立ちます。

また、8.4.11から8.4.12へのwal復元も問題なく機能します。

これがたまにしか起こっていない場合、私はあなたの説明がそこに到達するとは思わない。コードの修正が必要かどうかを判断できる人は、追加のトラブルシューティングを実際に使用できるように思えます。

2
Chris Travers