2

Ubuntu 10.04.2 LTS（プライマリおよびスタンバイ）でPostgreSQL9.1.3ストリーミングレプリケーションをセットアップしています。レプリケーションは、ストリームベースのバックアップ（pg_basebackup）で初期化されます。スクリプトは、を使用restore_commandしてリモートアーカイブの場所から必要なWALアーカイブをフェッチしようとしrsyncます。

restore_commandスクリプトが終了コード<>255で失敗した場合、すべてがドキュメントに記載されているように機能します。

起動時に、スタンバイは、restore_commandを呼び出して、アーカイブの場所で使用可能なすべてのWALを復元することから始まります。そこで利用可能なWALの最後に到達し、restore_commandが失敗すると、pg_xlogディレクトリで利用可能なすべてのWALを復元しようとします。それが失敗し、ストリーミングレプリケーションが構成されている場合、スタンバイはプライマリサーバーに接続し、アーカイブまたはpg_xlogで見つかった最後の有効なレコードからWALのストリーミングを開始しようとします。それが失敗した場合、またはストリーミングレプリケーションが構成されていない場合、または接続が後で切断された場合、スタンバイは手順1に戻り、アーカイブからファイルを再度復元しようとします。アーカイブpg_xlogからの再試行のこのループは、サーバーが停止するか、トリガーファイルによってフェイルオーバーがトリガーされるまで続きます。

ただし、restore_commandスクリプトが終了コード255で失敗すると（失敗したrsync呼び出しからの終了コードがスクリプトによって返されるため）、サーバープロセスは次のエラーで終了します。

2012-05-09 23:21:30 CEST - @  LOG:  database system was interrupted; last known up at     2012-05-09 23:21:25 CEST
2012-05-09 23:21:30 CEST - @  LOG:  entering standby mode
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: unexplained error (code 255) at io.c(601) [Receiver=3.0.7]
2012-05-09 23:21:30 CEST - @  FATAL:  could not restore file "00000001000000000000003D" from archive: return code 65280
2012-05-09 23:21:30 CEST - @  LOG:  startup process (PID 8184) exited with exit code 1
2012-05-09 23:21:30 CEST - @  LOG:  aborting startup due to startup process failure

だから私の質問は今です：これはバグですか、それとも他の優れたドキュメントに欠けている終了コード255の特別な意味がありますか、それともここで何か他のものが欠けていますか？

4

4 に答える 4

2

プライマリ サーバーでは、ディレクトリWALにファイルがあります。pg_xlog/ファイルがそこにある間WAL、PostgreSQL は要求された場合にそれらをスタンバイに配信できます。

通常、ローカルのアーカイブWAL場所もあり、ファイルが PostgreSQL によってそこに移動されると、オンラインのスタンバイにファイルを配信できなくなり、スタンバイはそれらが をWAL介してアーカイブされた場所から来ることを期待していますrestore_command。

プライマリ サーバーとスタンバイ サーバーでアーカイブされた s のセットアップの場所が異なる場合WAL、しばらくの間スタンバイに到達する方法がなく、ギャップが生じます。

あなたの場合、これは次のことを意味する可能性があります。

  • 00000001000000000000003Dプライマリ PostgreSQL によってアーカイブされていました。
  • スタンバイrestore_commandは、構成されたソースの場所からそれを認識しません。

scpまたはを使用して、不足している WAL ファイルをプライマリからスタンバイに手動でコピーすることを検討してrsyncください。また、WAL場所を確認し、両方のサーバーが同じ方向を向いていることを確認する必要がある場合もあります.

編集： ソース内でgrep-ing、それを参照するだけです。関数のほぼ最後 (9.1.3 ソースの場合は 3115 行目) で、正常に終了したか、シグナルを受信したかどうかのチェックがあります。restore_commandaccess/transam/xlog.cRestoreArchivedFilerestore_command

最初のケースでは、メッセージは に分類されDEBUG2ます。restore_commandそれ以外の信号を受信した場合SIGTERM(そして、それを適切に処理できなかったと思います)、FATALエラーが報告されます。これは、125 より大きいすべてのコードに当てはまります。

理由は教えませんが。ハッカーリスト
で質問することをお勧めします。

于 2012-05-09T21:51:57.850 に答える
0

コマンド プロセスからの高い終了ステータスに対するこの動作が選択された理由と、それを実装するための現在のコードを説明するコメントを次に示します。

    /*
     * Remember, we rollforward UNTIL the restore fails so failure here is
     * just part of the process... that makes it difficult to determine
     * whether the restore failed because there isn't an archive to restore,
     * or because the administrator has specified the restore program
     * incorrectly.  We have to assume the former.
     *
     * However, if the failure was due to any sort of signal, it's best to
     * punt and abort recovery.  (If we "return false" here, upper levels will
     * assume that recovery is complete and start up the database!) It's
     * essential to abort on child SIGINT and SIGQUIT, because per spec
     * system() ignores SIGINT and SIGQUIT while waiting; if we see one of
     * those it's a good bet we should have gotten it too.
     *
     * On SIGTERM, assume we have received a fast shutdown request, and exit
     * cleanly. It's pure chance whether we receive the SIGTERM first, or the
     * child process. If we receive it first, the signal handler will call
     * proc_exit, otherwise we do it here. If we or the child process received
     * SIGTERM for any other reason than a fast shutdown request, postmaster
     * will perform an immediate shutdown when it sees us exiting
     * unexpectedly.
     *
     * Per the Single Unix Spec, shells report exit status > 128 when a called
     * command died on a signal.  Also, 126 and 127 are used to report
     * problems such as an unfindable command; treat those as fatal errors
     * too.
     */
    if (WIFSIGNALED(rc) && WTERMSIG(rc) == SIGTERM)
        proc_exit(1);

    signaled = WIFSIGNALED(rc) || WEXITSTATUS(rc) > 125;

    ereport(signaled ? FATAL : DEBUG2,
            (errmsg("could not restore file \"%s\" from archive: %s",
                    xlogfname, wait_result_to_str(rc))));
于 2016-10-25T15:48:39.077 に答える
0

ホットスタンバイ（postgres 9.5）の作成でも同じ問題が発生しました。ストリーミングは機能していました (後でスタンバイの recovery.conf で使用されるのと同じ資格情報を使用して、pg_basebackup を介してスタンバイをシードしました)。

basebackup を取得した後、次の recovery.conf をセットアップします。

standby_mode = 'on'
primary_conninfo = 'host=ip.of.master port=5432 user=pgstandby password=password'
recovery_target_timeline = 'latest'
restore_command = 'sftp -q user@ip.of.wal.archive.host:data/master_wal_archive/%f "%p"'
trigger_file = '/srv/pgsql/9.5/data/trigger'

サーバーを起動すると、次のようになります。

2016-03-08 12:34:58.981 UTC  (/)LOG:  database system was interrupted; last known up at 2016-03-08 12:26:10 UTC
Couldn't read packet: Connection reset by peer
2016-03-08 12:34:59.525 UTC  (/)FATAL:  could not restore file "00000002.history" from archive: child process exited with exit code 255
2016-03-08 12:34:59.526 UTC  (/)LOG:  startup process (PID 26636) exited with exit code 1
2016-03-08 12:34:59.526 UTC  (/)LOG:  aborting startup due to startup process failure

recovey.conf から restore_command ラインを削除すると、スタンバイは正常に起動し、マスターから WAL のストリーミングを開始しました。

最終的に、WALアーカイブホストのauthorized_hostsファイルにスタンバイpostgresユーザーの公開鍵を追加しなかったことに問題を突き止めました。また、WAL アーカイブ ホストのサーバー フィンガープリントをスタンバイ postgres ユーザーの known_hosts ファイルに追加するのを忘れていました。

これらの 2 つの間違いが原因で、sftp の restore_command がコード 255 で終了していたと思います。始めることを拒否するのではなく。実際には、終了コードが特定の数値 (vyegorov のソース コードの grep が示唆するように 125 でしょうか?) よりも大きい場合、これは当てはまらないようです。

2 つの SSH の問題を修正すると、recovery.conf にある restore_command でスタンバイが正常に開始されました。

于 2016-03-08T13:39:34.423 に答える
0

これは、NFS (ポート 837 で rpcbind/rstatd を使用) を使用して一時的に発生した rsync の問題のようです。

$ rsync -avz /var/backup/* backup@storage:/data/backups
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: unexplained error (code 255) at io.c(600) [sender=3.0.6]

これは私のためにそれを修正しました：

service rpcbind stop
于 2014-05-27T07:19:43.393 に答える