私はしばらく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つであることが私の理解です。
何かアドバイスをいただければ幸いです。
「データベースシステムが起動しています。」というメッセージエラーを示すものではありません。 FATALレベルにある理由は、log_min_messages
の設定に関係なく、常にログに記録されるようにするためです。
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ディレクトリ、またはアーカイブディレクトリからコピーしていますか?
9.1ではなく9.3を使用していたことを除いて、これにもいくつか問題がありました。とにかく、修正はかなり簡単なものであることがわかりました。
_postgresql.conf
_ファイルがマスターからスレーブにコピーされていたため、スレーブで変更せずにそのままにしていました。 _recovery.conf
_ファイルを追加するだけですべてが機能するはずだと思いました(うまくいきましたが、複製されたスレーブサーバーにログインできませんでしたが、複製されていました)。
私はスレーブの_postgresql.conf
_ファイルを編集しました:
archive_mode=on
_をコメントアウトしましたarchive
コマンドをコメントアウトしました。そしてhot_standby=on
_これで、データベースを読み取り専用サーバーにして、読み取り専用クエリを受け入れる準備ができました。
スレーブのbootstrapディレクトリを作成する_pg_basebackup
_というスクリプトがあります。これは、データベースが含まれているデータディレクトリです。_postgresql.conf
_を変更する必要があります説明したようにスレーブとして使用できるようになる前のファイル、ポスト_pg_basebackup
_スクリプトではかなり単純なもの。
興味深いことに、私はこれをパウロとは逆の方法で解決しました。
追加した:
hot_standby = on
または、むしろ#hot_standby = off
上記に。 (これは9.5を使用していました)
私はこれをログに入れました:
MSK FATAL: the database system is starting up
サーバーの無限起動を修正するには、次のようにします。サービスを停止し(存在する場合)、プロセス「postgres」を終了します(通常は存在します)。これをコンソールで実行します。
pg_resetxlog.exe -D ../Data -f
これは、xLogディレクトリにデータがあり、サービスがシャットダウンする前に書き込まれないためです。そして、サービスの起動時に彼はそのデータを修正しようとします。時々、それは起動をフリーズさせて、決して終わらない。未修正データの一部が失われる可能性がありますが、データベースサーバーは正常に実行され、アプリからアクセスできます。