web-dev-qa-db-ja.com

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

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

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

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

マスターサーバー構成:

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

ホストレプリケーションpostgres IPAddressOfSlaveServer trust 

postgresql.conf:

 wal_level = hot_standby 
 max_wal_senders = 5 
 listen_address = '*' 
 port = 5432 
 max_wal_senders = 5 
 wal_keep_segments = 32 

スレーブサーバー構成:

postgresql.conf:

 hot_standby = on 

recovery.conf:

 standby_mode = on 
 primary_conninfo = Host = IPAddressOfMasterServer 
 port = 5432 
 user = 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\
 --exclude 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で一貫したリカバリ状態に達しました
ログ:REDOが0/BF000020で開始します
ログ:アーカイブからログファイル "logFileName"を復元しました
ログ:ログファイル0、セグメント192の予期しないpageaddr 0/85000000、オフセット0 
ログ:ログファイル0、セグメント192の予期しないpageaddr 0/85000000 、オフセット0 
ログ:ストリーミングレプリケーションは正常にプライマリに接続されました

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

何かアドバイスをいただければ幸いです。

16
Jen

「データベースシステムが起動しています。」というメッセージエラーを示すものではありません。 FATALレベルにある理由は、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に達しました

そして:

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

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

「Success。You can start ...」というメッセージはinitdbによって生成され、スレーブのセットアップの一部として実行されるべきではありません。そこで何か混乱しているかもしれません。私はこれらの明らかに矛盾するステートメントについても心配しています:

Postgresを再起動した唯一の方法は、service 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ディレクトリ、またはアーカイブディレクトリからコピーしていますか?

11
kgrittn

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

_postgresql.conf_ファイルがマスターからスレーブにコピーされていたため、スレーブで変更せずにそのままにしていました。 _recovery.conf_ファイルを追加するだけですべてが機能するはずだと思いました(うまくいきましたが、複製されたスレーブサーバーにログインできませんでしたが、複製されていました)。

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

  • _archive_mode=on_をコメントアウトしました
  • archiveコマンドをコメントアウトしました。そして
  • コメントアウトした_hot_standby=on_

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

スレーブのbootstrapディレクトリを作成する_pg_basebackup_というスクリプトがあります。これは、データベースが含まれているデータディレクトリです。_postgresql.conf_を変更する必要があります説明したようにスレーブとして使用できるようになる前のファイル、ポスト_pg_basebackup_スクリプトではかなり単純なもの。

8
Greg

興味深いことに、私はこれをパウロとは逆の方法で解決しました。

追加した:

hot_standby = on

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

7
user41734

私はこれをログに入れました:

MSK FATAL:  the database system is starting up

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

pg_resetxlog.exe -D ../Data -f

これは、xLogディレクトリにデータがあり、サービスがシャットダウンする前に書き込まれないためです。そして、サービスの起動時に彼はそのデータを修正しようとします。時々、それは起動をフリーズさせて、決して終わらない。未修正データの一部が失われる可能性がありますが、データベースサーバーは正常に実行され、アプリからアクセスできます。

1