web-dev-qa-db-ja.com

PostgreSQLが起動可能/復元可能になるのを待つ方法は？

カスタムLinuxディストリビューションを実行している仮想マシンでPostgreSQL 8.2.1から9.2へのアップグレードをテストしています。アップグレード手順は次のとおりです。

  1. pgサービスを開始します
  2. すべてのDBをバキュームします（これが必要かどうかは不明です）
  3. pg_dumpallでバックアップ
  4. pgサービスを停止します
  5. データが保存されているディレクトリを移動します（/var/pg;これはシンプルな単一サーバーのセットアップです）
  6. PostgreSQL 9.2をインストールする
  7. initdb
  8. サーバーを起動する
  9. ダンプされたデータを復元する
  10. reindexdbすべてのDB
  11. referential_constraintsビューを再作成します
  12. すべてのDBをバキュームします（このアップグレード後にAFAIKが必要です）

この手順は、1つのホストで問題なく動作し、問題なくバックアップおよび復元できます。異なるデータベースポイント1から7を持つ別のマシンでは正常に動作しますが、initdbの後にsleep 1を追加しない限りサーバーは起動しません。 「データベースシステムが起動しています」。これらのひどいハックを除いて、これに対処する標準的な方法は何ですか？

  1. sleepingは、いずれかの操作の前にある程度の時間をかけてください。
  2. 動作するまで、または十分なタイムアウトになるまでループするか、
  3. 簡単なクエリを受け入れるか、タイムアウトに達するまでループします。

編集： " solution "は結局機能しませんでした。 データベースが復元を実行する準備ができていることを確認するために何が必要ですか？

postgresqlrestoreupgrade
8
l0b0

initdbは終了するまで戻りません。そのため、initdbとサーバーの起動の間に一時停止は必要ありません。 PostgreSQLにはバグがあり、最初にすべてをディスクにフラッシュせずに完了しました。私は今のところ左については知りませんが、バグの性質はあなたがそれらについて常に知っているわけではないということです。

pg_ctl コマンドを使用してデータベースを起動する場合は、「-w」パラメーターを使用して、起動が完了するまで待機してから戻ります。特別なことは何もしません。「まだ準備ができていますか？」あなたのためのループ。

サーバーが起動する前に再生する必要のある大量のデータでサーバークラッシュが発生した場合、pg_ctlの待機中に "-t"で設定されたタイムアウトが小さすぎる可能性があることに注意してください。

ソースデータベースのpg_dumpを実行する前に、ソースデータベースをVACUUMする理由はありません。ダンプが少し速くなるかもしれませんが、バキューム自体はその改善よりも時間がかかります。

5
Greg Smith

の ワーキング 壊れたソリューションは、関連するポートが使用されているかどうかを繰り返し確認するようにinitスクリプトを変更することでした。 1分経っても表示されない場合は、起動に失敗したと見なされます。疑似コード：

start() {
    pg start
    checks=0
    while checks < 30:
        return true if the port is in use
        sleep 2
        checks++
    return false
}

編集：これはnotで十分であることがわかります。復元手順：

PGOPTIONS='--client-min-messages=warning' psql \
    --no-psqlrc \
    --variable=ON_ERROR_STOP=1 \
    --quiet \
    --log-file="$restore_log" \
    --single-transaction \
    --username postgres \
    --file="$sql_backup"

エラーメッセージ：

psql: FATAL:  the database system is starting up
2
l0b0