大規模リストア、途中で失敗

[mmcc (Matthew McClure)]

こんにちは！以前投稿した移行作業を一時中断していましたが、再開しました。元のインストール環境が古くなっていることによる問題が少し緊急性を帯びてきたためです。

背景：新しいインスタンスへの移行中に、外部のPG（PostgreSQL）およびRedisインスタンスへの移行も同時に行うことにしました。新しいインストールのセットアップは問題なく完了し、移行自体はコマンドラインからのバックアップと復元で行う予定です。現在、元のインスタンスを読み取り専用に設定して続行する前に、ワークフローをテストして、新しく復元されたインスタンスが期待どおりに機能することを確認しようとしています。特に、これはかなり古く、規模の大きいインスタンスを移行しているためです。

古いインスタンス：シンプルなセルフホスティングセットアップ、標準のコロケーションされたPG、Postgres、Redisを持つ1つのインスタンス。
新しいインスタンス：同じapp.ymlですが、外部のマネージドPG + Redis（DigitalOcean）を使用。

復元コマンドはしばらくの間正常に進んでいるように見えます。その後、かなりの時間が経過した後、以下のようなエラーが常に発生します（コンテキストとしていくつかの成功ログを含みます）。

COPY 99820
COPY 3216770
COPY 3251307
SSL connection has been closed unexpectedly
FATAL:  terminating connection due to administrator command
CONTEXT:  COPY post_timings, line 63404000: "8311	4897	1816	6999"
SSL connection has been closed unexpectedly
FATAL:  terminating connection due to administrator command
CONTEXT:  COPY post_timings, line 63404000: "8311	4897	1816	6999"
invalid socket
connection to server was lost
EXCEPTION: psql failed: connection to server was lost
/var/www/discourse/lib/backup_restore/database_restorer.rb:95:in `restore_dump'

実行ごとに異なる具体的なコピーポイントで発生しているため、私の知る限り、これは移行自体に固有の問題ではありません。明らかにDB接続はすべて機能していることを考えると、これはDigitalOceanの動作に関連する何らかの問題であると安全に推測できますが、この種の状況を経験したことがある人がいれば、正しい方向性を示唆してくれることを願っています。

[supermathie (Michael Brown)]

これはマネージド PG インスタンスなので、そのサービスのログを確認する必要があります。

（常にログを確認してください！）

たとえば、最大接続有効期間が構成されており、リストアの完了に時間がかかりすぎているために発生した理由がログに記載されている場合があります。

[mmcc (Matthew McClure)]

ええと…ええと…ログを確認しましたが、Discourseのログで見ていた情報とほとんど同じでした。しかし、それらを掘り下げていくうちに、その頃の履歴グラフを確認することになりました…テスト用DBのサイズが小さすぎました:facepalm:。そのため、いっぱいになってしまい、DOは接続を切断しました。しまった。

すべてサイズ変更し、愚かだと感じていますが、レースに戻りました。