何をしてほしいですか?
私のDiscourseのインストールは3年間順調に動作していました。Dockerを手動でアップデートしたところ、すべてが壊れてしまいました。サーバーにはリカバリーモードでしかアクセスできません。Dockerを起動できません。ハードドライブから(リカバリーモードではなく)サーバーを起動すると、SSHで接続できません。
いつまでに必要ですか?
Discourseを再び動作させてください!
2ヶ月前のスナップショットがありますが、できれば過去2ヶ月間のデータは失いたくありません。Dockerが壊れた直後のスナップショットもあります。
数時間前に開発者を雇いましたが、彼にとっては時間が遅いためプロジェクトを完了できませんでしたが、できるだけ早くこれを修正する必要があります。これは本番サイトです。
彼は次のように述べています。
標準的なチェックはすべて行われ、sshは機能しており、トラフィックはブロックされていません。ssh設定をパスワード認証を使用するように更新しました。何をする必要があるかというと、この破損が発生する前の手順を調査し、関連するログを調査することです。
このタスクのために、USDでいくらの予算を提供できますか?
タスクには時給で、市場価格で支払います。あなたのレートを教えてください。
「いいね!」 2
jericson
(Jon Ericson)
2
DMを送りました。そこで申し上げたように、新しいDropletを起動するのが最も早いかもしれません。
「いいね!」 3
@jericson、ご協力いただき誠にありがとうございました!
最終的に行ったことは以下の通りです。
- 古いサイトへのリカバリアクセスを取得する
- ネットワークドライブ(Digital Ocean Volume Block Storage)を接続する
/var/discourse ファイルの zip(tar ボールを作成)
- それらのファイルをネットワークドライブに転送する
- 古いサーバーをシャットダウンし、ネットワークドライブを切り離す
- 新しいサーバーに新しい Discourse 組織を構築する
- ネットワークドライブを接続する
- ファイルを展開する
- 7日間のバックアップからバックアップを見つける
- その時点まで復元する
/var/discourse フォルダー全体を新しいサーバーに移動しようと試みましたが、Redis の問題が発生しました(それが根本的な問題だったかどうかは不明ですが、それがフラグが立てられたものでした)。
ジョン、改めてご協力に感謝いたします。ありがとうございました!
「いいね!」 5
Lilly
(Lillian Louis)
4
「いいね!」 4
ただ気になっただけです。DockerとDigitalOceanに関連する最近のアップグレード失敗のメッセージがいくつかありますが、これは偶然でしょうか、それともDigitalOceanでアップグレードする他のDiscourse管理者が遭遇する可能性のある共通の原因があるのでしょうか?私もその一人なので質問しています。
@waffleslop @jericson 素晴らしい仕事と、修正のために行ったことについての情報投稿、ありがとうございます。セルフホスティング者として、問題が発生した場合にそのようなリソースがあるのは常に良いことです!
@icaria36 私はほとんどのインスタンスでDigital Oceanを使用しており、OSとDiscourseのコードベースの両方を最近問題なくアップグレードしました。(これを投稿しても、私に呪いが来ないことを願っています!)
「いいね!」 2
アップグレードは昨日までずっと簡単でした。GUIからDockerを更新し、うまくいきました。次に、残りの3つの項目を更新しようとして、そのうちの1つ(どれだったか忘れてしまいました)を最初に押しました。何も起こりませんでした。数秒待ってから、もう一つ…さらにその次を押しました。おそらく、早すぎたため、物事が詰まってしまったのでしょうか?コンソールにログインしたところ、再起動が推奨されるというメッセージが表示されたので、マシンを再起動しました。その後、完全にオンラインに戻ることはありませんでした。
アップグレード/更新中に再起動してしまった可能性があります。これを書いている今、それは愚かなことだったと感じています!
「いいね!」 3
jericson
(Jon Ericson)
8
問題の原因を調べる時間はかけませんでした。なぜなら、@waffleslop をできるだけ早く稼働させたかったからです。私は、コマンドラインを使用しているため、問題なく Discourse(DigitalOcean 上でホストされています)サーバーをアップグレードしました。GUI ではなく、非標準インストール を使用しています。
ダウンタイムの延長リスクを最小限に抑えるために、いくつか推奨できることがあります。
- 何かを行う前に必ずバックアップを作成してください! アップデートを実行する前に、インターフェースにバックアップを強く推奨する警告を表示すべきではないかと思います。最近のバックアップがあれば、最悪の場合でも新しいDropletを起動して復元できるという安心感があります。
- バックアップにアクセスできることを確認してください! @waffleslop と私は、
/var/discourse のコピーを新しいDropletに取得する方法を理解するのにかなりの時間を費やしました。元のDropletで非常に奇妙なことが起こっており、ファイルを新しいDropletに scp することができませんでした。私のサーバーでは、バックアップをS3に保存し、毎晩ローカルマシンにコピーしています。これは過剰でしょうか?おそらく。しかし、何らかの理由で問題が発生した場合、多くの選択肢が与えられます。
- 時々バックアップをテストしてください。 本番サーバーがダウンしているときは、自分が何をしているか自信を持ちたいものです。理想的には、本番環境で問題が発生した場合にフォールバックできる場所があるように、アップデートを実行する直前にバックアップをテストすることになるでしょう。しかし、プロセスを新鮮に保つために、必要な頻度でバックアップを試すことは通常十分です。
- 二人寄れば文殊の知恵。 これは自己利益の発言かもしれませんが、このような状況の経験がある人と画面共有で通話できれば、緊急事態を乗り越えるのがはるかに簡単になることがあります。理想的には、コマンドラインの使い方を知っている人 が望ましいでしょう。
バックアップさえ作成しておけば、アップグレードはかなり安全に行えるはずです。
「いいね!」 5
system
(system)
クローズされました:
9
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.