ブートストラップのビルドエラー

エラーコードに基づき、Upgrade gone sideways [deprecated Guest Gate plugin] のような問題だと考え、プラグインを最新の状態にすることに集中していました。しかし、古いPSQLを手動で強制した可能性もあり、その修正後に古いプラグインをクリーンアップした(そしてそれが問題を正しく解決した)という可能性もあります https://meta.discourse.org/t/upgrade-gone-sideways-deprecated-guest-gate-plugin/241692/3。

しかし、それを解決するのは私のスキルレベルを超えていると思います。:slight_smile: そのトピックから何か追加の手がかりはありますか?

私も以前それを見ていましたが、残念ながら私を助けるものは何も見つかりませんでした。フォーラムのデータが消去されないことを本当に願っています。バックアップを作成してから非常に長い時間が経過しているため、データを失うと信じられないほど悲しむでしょう。

既存のコンテナを起動して、再構築前のバージョンを立ち上げ、続行する前にバックアップを取っていただけますか?

./launcher start app

残念ながら、コンテナはもう存在しないと思います。試していた修正は、Dockerを完全にアンインストールして再インストールすることでしたが、既存のコンテナはなくなってしまいました。そのため、今そのコマンドを実行しようとすると、以下のようになります。
image

この記事も見つけました:Database system was not properly shut down error when rebuilding - support - Discourse Meta

見つかる情報がすべてデータ損失を示唆しているようで、本当に落ち込み始めています。

唯一見つけられるバックアップが1年前のものなので、データ損失なしでこれを修正する方法を見つけるのを誰かに助けてもらえればと切に願っています。

おそらく関係ないと思いますが、カーネルのバージョン4.15.0-91は、約30ヶ月前のもので、少し古いのではないでしょうか?

まあ、私がサーバーを立ち上げたときから pretty old ですね(笑)。でも、それとは関係ないはずです。これまでずっと問題なく起動していましたから。

「いいね!」 1

データ破損/損失の可能性もあるが、古いカーネルとDocker 20.10の間の奇妙な依存関係の問題でpsqlが起動できなかったという方がましだと思う…でも、それは可能性が低いとは思うけどね :roll_eyes: そうなると「なぜ今になって?」という疑問が出てくるだろう。

これは本当に疑わしいです。データベースのシャットダウンプロセス中にDockerを停止してアンインストール/再インストールしたに違いありません。しかし、確信はありません。

「いいね!」 2

/var/discourse/shared/standalone の内容は?

「いいね!」 1

ls /var/discourse/shared/standalone を使用して見つけます

「いいね!」 1

別のボリュームに移動しました。以下にその内容を示します。

root@discourse:/var/discourse# ls /mnt/volume-2/standalone/ -al
total 64
drwxr-xr-x 16 root            root     4096 Feb  5  2021 .
drwxr-xr-x  3 root            root     4096 Aug 30  2020 ..
drwxr-xr-x  3            1000 www-data 4096 Aug 30  2020 backups
drwxr-xr-x 10 root            root     4096 Nov 20 08:35 letsencrypt
drwxr-xr-x  4 root            root     4096 Aug 30  2020 log
drwxr-xr-x  2 systemd-resolve input    4096 Aug 30  2020 postgres_backup
drwx------ 19 systemd-resolve input    4096 Nov 20 12:01 postgres_data
drwx------ 20 uuidd           uuidd    4096 Feb  5  2021 postgres_data_old
drwxrwxr-x  5 systemd-resolve input    4096 Nov 20 12:01 postgres_run
drwxr-xr-x  2 messagebus      syslog   4096 Nov 20 08:38 redis_data
drwxr-xr-x  2 root            root     4096 Dec  1  2020 ssl
drwxr-xr-x  3 root            root     4096 Aug 30  2020 standalone
drwxr-xr-x  4 root            root     4096 Aug 30  2020 state
drwxr-xr-x  4            1000 www-data 4096 Nov 20 08:36 tmp
drwxr-xr-x  2 root            root     4096 Aug 30  2020 uploads
drwxr-xr-x  4 root            root     4096 Aug 30  2020 uploads.orig

コンテナがなくても、データベースの状態が一部残っている可能性があります。実験する際は、これを安全な場所にコピーしておいてください。

設定されている方法では、Dockerボリューム上にあるため、通常はコンテナ内からDBにアクセスできます。

コンテナを再度構築できれば、これに再びアクセスできる可能性があります。そうでなければ、サーバーにPostgresをインストールする必要があります(ただし、すべてが再び機能するようになれば冗長になります)。

再構築を機能させること自体が一番難しい部分なんだ。それができないと、どうやらお手上げ状態になってしまう。

でも、念のためこのフォルダの内容はローカルマシンにコピーしておくよ。

Postgresのアップデートに失敗したように見えます。@Headless、最後にコマンドラインからサイトを更新したのはいつですか?

更新とは、プルして再構築することですか?数ヶ月に一度程度行っています。

最新のバックアップは何ですか?

ls /var/discourse/shared/standalone/backups ですか?

それは以前に言及された、1年前のバックアップです。

結局、バックアップをオフにした時期があったので、それは私のせいです。

このサイトを復旧するには、非常に冒険的なロデオになるでしょう。しばらくの間、これらの復旧を行っていないため、記憶が少し鈍っています。復旧の手順が記載されている既存のトピックを見つけられるか見てみましょう。

ご支援ありがとうございます!