私は使い捨て仮想マシンでランダムな時点にそれらを復元することにより、私のpostgresql 10.8バックアップをテストするプロセスを設計しています。しかし、プロセスを完全に自動化することはできませんでした。 公式ドキュメントのステップ8(セクション25.3.4)でブロックされています
- サーバーを起動します。
Ssh経由でpg_ctl start
を実行すると、コマンドが強制終了されるまでハングします。 VM=に直接sshを実行してpg_ctl start
を実行すると、コマンドは期待どおりにすばやく戻ります。
2012 のこのスレッドは、同様のシナリオを説明しているようです。しかし私の場合、postgresプロセスdoesは、ハングしている間に呼び出しセッションが強制終了されても正常に開始します(おそらく9.0.5と10.8の間の改善ですが)。 ?)。
このgithubの問題 は関連があるようですが、悲しいことに、私が知らない言語での長い書き換えによって「解決」され、最終的にpg_ctl
バイナリのバグであると結論付けました。
手順8を自動化して、バックアップメディアの後続の検証テストに進むにはどうすればよいですか?
これは、ハックする必要があるバイナリの未解決のバグですか?または私は賢明な実装を見逃しましたか?
pg_ctl
は出力用の実際の端末を必要としているように見えますが、単にコマンドを実行するように要求すると、ssh
によって割り当てられません。 Postgresマニュアル によると
Unixライクなシステムでは、デフォルトで、サーバーの標準出力と標準エラーはpg_ctlの標準出力に送信されます(標準エラーではありません)。次に、pg_ctlの標準出力をファイルにリダイレクトするか、rotatelogsなどのログローテーションプログラムなどの別のプロセスにパイプします。それ以外の場合、
postgres
は(バックグラウンドから)制御端末に出力を書き込み、シェルのプロセスグループを離れません。 [...]これらのデフォルトの動作は、-l
を使用してサーバーの出力をログファイルに追加することで変更できます。-l
または出力リダイレクトの使用をお勧めします。
したがって、pg_ctl
オプション(-t
)を使用してssh -t somehost "pg_ctl start"
に端末を割り当てるようにssh
に指示するか、pg_ctl
にnot端末に書き込みます(ssh somehost "pg_ctl start >/dev/null"
またはssh somehost "pg_ctl start -l /tmp/start.log "
)