PostgreSQL 9.1ホットバックアップエラー:データベースシステムが起動しています


16

私はしばらくの間Postgres 9.1のホットバックアップに取り組んできましたが、一貫した問題に遭遇しました。スレーブサーバーでPostgresを再起動すると、pgstartlogログファイルとpg_logディレクトリの下の日次ログファイルがエラーなしで読み込まれます。ただし、psqlコマンドを使用してデータベースに入力しようとすると、エラーが発生します。

FATAL:データベースシステムが起動しています。

また、recovery.confファイルはrecovery.doneにはなりません。私はこのエラーを徹底的に調査し、一貫して同じ応答を見つけました。Postgresを再起動しようとする前にデータベースが完全にシャットダウンされていません。Postgresを再起動した唯一の方法は、service postgresql-9.1 restartor /etc/init.d/postgresql-9.1 restartコマンドを使用することです。このエラーを受け取った後、すべてのプロセスを強制終了し、データベースを再起動しようとしますが、それでも同じエラーを受け取ります。ここからどこへ行くか、この問題を修正する方法が不足しています。以下は、ホットバックアップを完了するために行った正確なプロセスです。

マスターサーバーの構成:

pg_hba.conf、次の行を追加しました:

ホスト複製postgres IPAddressOfSlaveServer信頼

postgresql.conf:

wal_level = hot_standby
max_wal_senders = 5
listen_address = '*'
ポート= 5432
max_wal_senders = 5
wal_keep_segments = 32

スレーブサーバーの構成:

postgresql.conf:

hot_standby = on

recovery.conf:

standby_mode = on
primary_conninfo = host = IPAddressOfMasterServer
ポート= 5432
ユーザー= postgres
restore_command = 'cp /var/lib/pgsql/9.1/data/pg_xlog/%f "%p"'

両方のサーバーを構成した後

マスターサーバー上のpostgresユーザーに変更し、コマンドを実行します。

psql -c "Select pg_start_backup( 'label'、true);";
rsync -a -v -e ssh /var/lib/pgsql/9.1/data slave:/var/lib/pgsql/9.1/data \
        -postmaster.pidを除外
pgsql -c "select pg_stop_backup();";

データベースをスレーブサーバーと同期した後

スレーブサーバーを再起動しても、起動は失敗しません。pgstartup.logの読み取り:

成功。これで、次を使用してデータベースサーバーを起動できます。

    /usr/pgsql-9.1/bin/postgres -D /var/lib/pgsql/9.1/data
または
    /usr/pgsql/9.1/bin/pg_ctl -D /var/lib/pgsql/9.1/data -l logfile start

当日のログファイルpostgresql-Thu.logは次のように読み取ります。

ログ:シャットダウン
ログ:データベースシステムがシャットダウンされました
ログ:2012年4月10日にデータベースシステムが復旧中にシャットダウンしました
ログ:スタンバイモードに入る
ログ:アーカイブからログファイル「logFileName」を復元しました
ログ:0 / BF0000B0で一貫性のある回復状態に達しました
ログ:0 / BF000020からやり直しを開始
ログ:アーカイブからログファイル「logFileName」を復元しました
ログ:ログファイル0、セグメント192、オフセット0の予期しないpageaddr 0/85000000
ログ:ログファイル0、セグメント192、オフセット0の予期しないpageaddr 0/85000000
ログ:プライマリに正常に接続されたストリーミングレプリケーション

予期しないpageaddrを調査し、postgresアーカイブから、それが非常に正常であり、WALの終わりを検出する予想される方法の1つであることを理解しています。

どんなアドバイスも大歓迎です。

回答:


11

「データベースシステムが起動しています。」というメッセージ エラーを示すものではありません。致命的レベルにある理由は、次の設定に関係なく、常にログに記録されるようにするためですlog_min_messages

http://www.postgresql.org/docs/9.1/interactive/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN

rsyncの後、表示されているものを実際に実行しましたか?:

pgsql -c "select pg_stop_backup();";

私の知る限りpgsql、バックアップが完了せず、スレーブが回復モードから抜け出すことのできる実行可能ファイルは存在しないためです。一方で、多分あなたは本当に実行したのかもしれません。psqlそうしないと、スレーブが次のような成功メッセージを記録する方法がわかりません。

ログ:0 / BF0000B0で一貫性のある回復状態に達しました

そして:

ログ:プライマリに正常に接続されたストリーミングレプリケーション

この時点でスレーブに接続しようとしましたか?どうした?

あなたが言及した「成功しました。今すぐ開始できます...」というメッセージはによって生成されますがinitdb、これはスレーブのセットアップの一部として実行されるべきではありません。そこに何か混乱しているかもしれません。私はこれらの明らかに矛盾する声明についても心配しています:

Postgresを再起動した唯一の方法は、postgresql-9.1 restartサービスまたは/etc/init.d/postgresql-9.1 restartコマンドを使用することです。このエラーを受け取った後、すべてのプロセスを強制終了し、データベースを再起動しようとします...

サービススクリプトを使用してサービスを停止しようとしましたか?どうした?行の前に詳細情報を追加すると、ログを理解するのに役立つ場合があります。を使用しております:

log_line_prefix = '[%m] %p %q<%u %d %r> '

recovery.confスクリプトは奇妙に見えます。マスターのpg_xlogディレクトリ、スレーブのアクティブなpg_xlogディレクトリ、またはアーカイブディレクトリからコピーしていますか?


8

9.1ではなく9.3を使用していたことを除いて、これにもいくつかの問題がありました。とにかく、修正はかなり簡単であることが判明しました。

postgresql.confファイルには、マスタからスレーブにコピーされていた、と私は、スレーブに変更されていないことを残していました。あなたがしなければならないのはrecovery.confファイルを追加するだけで、すべてが機能すると思いました(まあうまくいきましたが、複製されたスレーブサーバーにログインできませんでしたが、複製されていました)。

私はスレーブのpostgresql.confファイルを編集しました:

  • コメントアウト archive_mode=on
  • コメントアウトされたarchiveコマンド。そして
  • コメントアウト hot_standby=on

それでできました。データベースを読み取り専用サーバーとして、読み取り専用クエリを受け入れる準備ができました。

pg_basebackupスレーブ用のブートストラップディレクトリを作成するというスクリプトがあります。これは、データベースが含まれるデータディレクトリです。postgresql.conf説明したように、スレーブとして使用する前にファイルを変更する必要がありpg_basebackupます。これは、ポストスクリプトにとっては非常に簡単なことです。


1
「commented out hot_standby = on」と書くとき、「前に#-comment-markを削除して、実際にhot_standbyを有効にする」ことを意味すると思います:) hot_standbyでない場合、dbは常に設計により「起動」します(暖かいです)スタンバイ、フェールオーバーの準備はできていますが、クエリは行いません)。マスターでwal_level = hot_standbyを使用せずにベースバックアップダンプを作成し、スレーブでhot_stanbyをオンにした場合、hot_standbyを起動して実行するにはスレーブデータベースを再ダンプして再起動する必要があります。そうしないと、致命的なエラーが発生します。
フレデリクストラックシェーニング

hot_standby = onが必要で、そこにある必要があります
Abhilash Mishra

7

興味深いことに、私はポールとは反対の方法でこれを解決しました。

追加した:

hot_standby = on

または、むしろ#hot_standby = off上記に変更されました。(これは9.5を使用していました)


1

私はログでこれを得ました:

MSK FATAL:  the database system is starting up

サーバーの無限起動を修正するには、次の操作を行います。サービスを停止し(存在する場合)、プロセス 'postgres'を強制終了します(通常は存在します)。コンソールでこれを実行します:

pg_resetxlog.exe -D ../Data -f

この問題は、xLogディレクトリにデータがあり、サービスがシャットダウンする前に書き込まれないために発生します。そして、サービスの起動時に、彼はそのデータを修正しようとします。ときどき起動がフリーズし、終了しないことがあります。アップのコマンドは、この未修正データをクリーンアップし、修正済みデータのみで起動するサービスを適用します。固定されていないデータの一部が失われることもありますが、データベースサーバーは正常に動作し、アプリからアクセスできます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.