復元時に失敗しないように、重複キータグを削除するためにバックアップ内のデータベースを変更する

これは私の過去24時間の非常に簡潔な投稿ですが、実際にはまだ機能していないため、どこで間違ったのかを誰かが下に投稿してくれることを願っています。

私のDiscourseのアップデートは、重複キーが原因で失敗しました。私のタグの1つが重複しています。アップデートの問題を解決するために、Discourseをクリーンインストールしてから最新のバックアップをロードする必要がありましたが、重複キーについてエラーが発生するため、ロードが失敗します。そのため、バックアップの内部に入って、問題のあるタグを別のものに変更する必要がありました。

何らかの理由で、重複タグの問題が修正された再圧縮バックアップは、元のバックアップよりも大幅に小さくなり、リストアしようとすると失敗するため、再圧縮プロセスで何かがうまくいかなかったようです。

1) バックアップの場所: Discourseのバックアップを見つけるには、次のコマンドを使用できます。

sudo find / -name "*.tar.gz"

これにより、システム全体で拡張子が「.tar.gz」のすべてのバックアップファイルが検索されます。デフォルトでは、コンテナ内の shared/backups/default にあるはずです。

2) コピーの作成: 作業したいバックアップを見つけたら、元のファイルのバックアップを確実に保持するために、そのコピーを作成します。「cp」コマンドを使用します。

bash

sudo cp /path/to/original_backup.tar.gz /path/to/copy_backup.tar.gz

3) コピーの展開: 「tar」コマンドを使用して、コピーされたバックアップファイルの内容を展開します。

bash

tar -xzvf /path/to/copy_backup.tar.gz

これにより、バックアップファイルが一時ディレクトリに展開されます。

4) データベース内のタグの編集: 展開されたバックアップファイルに移動し、テキストエディタを使用して関連するデータベースファイルを開きます。重複する「socialmedia」タグの問題に遭遇し、それが正常なリストアを妨げました。大きなデータベースにはタグのインスタンスがたくさんあり、検索している特定のタグも同様である可能性が高いため、「immutable socialmedia」をNanoでCtrl Wを使用して検索したところ、すぐにその場所にたどり着きました。

sudo nano /path/to/extracted_database.sql

「socialmedia」タグのインスタンスを1つ「socialmedia2」に変更し、その後、それが現在1回だけ表示されることを確認するために簡単な検索を行いました。リストアが成功したら、管理セクションからこれらのタグを修正できます。

5) 再圧縮: バックアップファイルを編集した後、修正されたコンテンツで新しいバックアップファイルを作成します。次のコマンドを使用して、変更されたファイルを圧縮します。

tar -czvf /path/to/new_modified_backup.tar.gz /path/to/modified_files_directory

6) 正しいファイルへの移動: 新しい変更されたバックアップファイルを、バックアップが保存されている適切なディレクトリに移動します。デフォルトの場所は通常「/shared/backups/default」です。

sudo mv /path/to/new_modified_backup.tar.gz /shared/backups/default/

7) サービスの停止と開始: 変更されたバックアップをリストアする前に、リストアプロセス中の潜在的な競合を回避するために、関連するサービスを停止していることを確認してください。Discourseアプリケーションを停止するには、「./launcher stop app」コマンドを使用します。

./launcher stop app

8) バックアップのリストア: 変更されたバックアップからリストアするには、「discourse restore」コマンドと新しいバックアップファイルへのパスを使用します。

discourse restore /shared/backups/default/new_modified_backup.tar.gz

または、サイトの /admin を介して行うこともできます。バックアップセクションに表示されるはずです。

9) リストアの検証: リストアプロセスが完了した後、Discourseアプリケーションとデータベースを確認して、重複する「socialmedia」タグが削除されたことを確認することで、変更が成功したことを検証しました。

10) サービスの開始: Discourseアプリケーションをオンラインに戻すために、以前に停止したサービスを再起動しました。Discourseアプリケーションを開始するには、「./launcher start app」コマンドを使用しました。

./launcher start app

11) 一時ファイルと追加バックアップの削除: バックアップのリストアが成功した後、ディスク容量を解放するために、プロセス中に作成された一時ファイルと追加バックアップを削除しました。ファイルを削除するには、「rm」コマンドを使用します。

sudo rm -r /path/to/temporary_directory
sudo rm /path/to/copy_backup.tar.gz
「いいね!」 3

なぜですか?

アプリを再起動したり、コンテナに入ったり、Postgres に入ったりしてから、すぐにデータ入力に対処したりして、この問題を「オンライン」で解決できなかったのはなぜですか?

「いいね!」 1

エラーを予期していなかったので、すでに新しいバージョンのDiscourseをサーバーに配置していました。重複キーエラーはバックアップ内にあり、クリーンインストールされたアプリにはありませんでしたが、エラーの修正を求められたため、バックアップを復元できませんでした。

そのため、バックアップ内のタグを編集しようとしました。

でも、アップデートのエラーを見ましたか?

次回からは、もっと楽をするために、その場で修正してください。

アプリが実行されておらず、リロードもできなかったため、それを修正しようとして最新の Discourse バージョンに更新しました。そのため、バックアップ以外の場所ではデータベースにアクセスできませんでした。

これは確かにニッチなケースですが、アプリのデータベースに直接アクセスできるうちに問題に気づいて修正するのが最善の方法でしたが、見逃してしまい、他に選択肢が見つかりませんでした。

「いいね!」 1

心配いりません。少なくとも、それが可能であることを示し、新しいことを学び、他の人に別の選択肢を提供しました。

よくできました! :clap:

「いいね!」 3

ありがとうございます。ただし、元のファイルは128MBでしたが、新しいファイルは29MBでした。そのため、サーバーでの再圧縮中にファイルが長すぎて切り捨てられた可能性があります。

このプロセスは機能するはずですが、最終的に得られたファイルは、私のディスコースを復元するために使用できませんでした。

「いいね!」 1

取った道はより危険でしたが、確実に実行可能でしたか?この問題について、誰かがアドバイスをくれるかもしれません。

バックアップからこれを繰り返すこともできるはずなので…

「いいね!」 1

この問題は解決しましたか? それはハウツーのように読めますが、あなたのサイトはまだ壊れているようです。

おそらく私が理解していないことをしているのでしょうが、通常は ./launcher start app を実行して古いコンテナを開始できるはずですが、そうできなかった理由がありましたか?

その後、Rails または SQL ツールを使用して古いコンテナでデータベースを修正してから、ブートストラップ/再構築を再度実行できます。

または、古いコンテナが処理できる範囲を超えてデータベースを移行したのかもしれません。

以前、サイトが1年以上前のバックアップに対して同様の処置を行いました。DBダンプは十分に小さかったため、vim で編集できたと思います。

「いいね!」 1

返信ありがとうございます。

数回のアップデートが遅れていたため、起動を拒否されました。そのため、新しいものを作成して古いバックアップをアップロードすることで最新の Discourse に更新しましたが、重複キーのためそのバックアップは拒否されました。

あるいは、古いコンテナでは処理できないほどデータベースを移行したのかもしれません。

はい、おそらくそうです。今となっては正確に何をしたかは少し曖昧ですが、ここでトラブルシューティングのアドバイスに基づいていくつかのことを個別に更新しました。そのうちの1つは、最新の PostgreSQL バージョンを取得することでした。

vim で編集できました。

Nano で編集でき、すべて問題ないように見えましたが、再圧縮されたファイルが小さすぎたため、どこかで何かがうまくいかなかったようです。もしかしたら Nano では編集できなかったのかもしれません。その時はうまくいったように見えました。

誰かがそれに誤りを見つけて修正してくれることを期待していました。そうすれば「ハウツー」ガイドになるでしょう。

次に確認すること:

  • すべての解凍をやり直します。そのままジップします。ジップサイズが以前と同じであることを確認します。そうでない場合は、同じオプションでジップしていない可能性があります。

  • 再度解凍し、編集するファイルのファイルサイズを確認します。編集し、保存し、サイズが大幅に変更されていないことを確認します。

「いいね!」 1

アップデートのお知らせです。先週、チームの別のメンバーがこれに取り組んでいましたが、解決策が見つからなかったため、ローカルシステムでDBを編集してもう一度試してみました。

行ったこと:

  1. 復元したい古いバックアップをダウンロードしました
  2. 7zipでファイルを解凍しました
  3. visual studio codeでdump.sqlを開きました
  4. DBで重複したタグを直接見つけました。
  5. 「 」でタグを検索して、タグのリストと思われるものを検索しました。私の場合は「socialmedia」です。タグは、見つかったインスタンスの最下部から2番目と3番目のようです。

  1. 1つを次のように編集しました

132 ‘socialmedia2’:1A socialmedia2 en_GB 3

  1. dump.sqlファイルを7zipで再圧縮しました
  • アーカイブに追加
  • アーカイブ形式 .gzip
  1. メインのバックアップファイルを再圧縮しました
  • アーカイブに追加
  • アーカイブ形式 .tar (gzipはまだ利用できません)
  1. これで、圧縮された.tar固定バックアップファイルが表示されるはずです。

  2. .tarファイルを7zipで圧縮して.tar.gzファイルを作成し、Discourseで使用されている形式に合わせます。

  • アーカイブに追加
  • アーカイブ形式 .gzip
  1. バックアップにアップロードし、管理セクションから復元します。

この時点でエラーメッセージが表示されました。

ダンプファイルを展開中…
[2023-08-08 15:09:15] EXCEPTION: No such file or directory @ rb_check_realpath_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

上記のプロセスで何か見落としたことはありますか?
考えられるのは、探しているパスが今日のの日付を使用しており、バックアップの日付ではないことだけです(私はこれを2023-08-08に書いています)。

これは、以前の投稿のフォローアップです。こちら 。もしうまくいけば、将来これを行う他の人が見つけやすいように、再度投稿します。

ラップトップでDBを編集するために行ったこと:

  1. 管理セクションから復元したい古いバックアップをダウンロードしました
  2. 7zipでファイルを解凍しました
  3. dump.sqlをVisual Studio Codeで開きました
  4. 重複したタグをDBで直接見つけました。
  5. タグを検索して、タグのリストと思われるものを検索しました。私の場合は「socialmedia」です。タグは、見つかったインスタンスの最下部から2番目と3番目のようです。

  1. 1つを次のように編集しました

132 ‘socialmedia2’:1A socialmedia2 en_GB 3

  1. dump.sqlファイルを7zipで再圧縮しました
  • アーカイブに追加
  • アーカイブ形式 .gzip
  1. メインのバックアップファイルを再圧縮しました
  • アーカイブに追加
  • アーカイブ形式 .tar (gzipはまだ利用できません)
  1. これで、zipされた.tarの修正済みバックアップファイルが表示されるはずです。

  2. Discourseで使用されている形式に合わせるために、.tarファイルを7zipでzipして.tar.gzファイルを作成します

  • アーカイブに追加
  • アーカイブ形式 .gzip
  1. バックアップにアップロードし、管理セクションから復元します。

この時点でエラーメッセージが表示されました。

ダンプファイルを解凍中…
[2023-08-08 15:09:15] 例外: ディレクトリまたはファイルが存在しません @ rb_check_realpath_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

上記のプロセスで何か見落としたことはありますか?
私が考えられる唯一のことは、探しているパスがバックアップの日付ではなく、今日の日付を使用していることです(これを書いているのは2023年8月8日です)。

「いいね!」 1

バックアップファイルの正確な名前が重要だと思います。フォーラム名、日付とタイムスタンプ、バージョン識別子です。したがって、展開、変更、再パッケージ化を行う場合は、元のファイルと同じ名前に再構築することをお勧めします。ただし、もちろん元のファイルは安全に保管してください。

「いいね!」 1

新しいトピックからの投稿をこの投稿にまとめました。この問題を1か所にまとめておくことで、今後の旅行者にとってずっと追いかけやすくなると思います。:+1:

「いいね!」 1

@Ed_Sさん、ありがとうございます。以前どこかで重要だと読んだので、元の名前をそのままにしておきました。上記の質問は、バックアップ復元ツールが探していて見つからなかったものについてです:/var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

これは、私が復元を実行していた日付です。

「いいね!」 1

ああ、すみません。それは奇妙なことのようです。一時ディレクトリが今日の年月に従って名前が付けられることが完全に期待されている可能性がありますが、sqlダンプファイルが見つからないのは良く見えません。

tarファイルのコンテンツを一覧表示すると、そのファイル名が表示されますか?私の場合は

root@ubuntu-2gb-nbg1-1:/var/discourse/shared/standalone/backups/default# tar vtfz forumname-2023-08-03-HHMMSS-v2023mmddhhmmss.tar.gz dump.sql.gz | head
-rw-r--r-- discourse/www-data 16336925 2023-08-03 05:31 dump.sql.gz
「いいね!」 1

Edさん、ありがとうございます。そのファイルは存在しませんでした。しばらくオフグリッドだったので、遅れて申し訳ありません。

正しい名前のファイルがそこにはないので、手動で空のファイルを作成してみました。

sudo mkdir -p /var/www/discourse/tmp/restores/default/2023-08-22-121010/

しかし、リストアを押すたびに、少し異なるファイル(最後の6桁)を探しています。タイムスタンプで生成されたフォルダを探しているのだと思いますが、リストアボタンを押すたびに探しているフォルダが変わっています。

ステップ10でtarファイルを作成する際に何か問題が発生しているのではないかと疑っています。確認できますか? file コマンドで説明できますか? tar tvfz で内容を一覧表示できますか?

「いいね!」 1