Staging の Discourse インスタンスでリストアを実行しようとしたところ、問題が発生しています。Staging は v2.4.0.beta1 +36 で動作しています。どこで問題が起きているか、またはどこを確認すべきかご存知でしょうか?事前にありがとうございます!
以下はログ出力の末尾です:
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] Migrating the database...
[2019-07-16 20:08:16] Reconnecting to the database...
[2019-07-16 20:08:16] Reloading site settings...
[2019-07-16 20:08:16] Disabling outgoing emails for non-staff users...
[2019-07-16 20:08:16] Clearing emoji cache...
[2019-07-16 20:08:16] Disabling readonly mode...
[2019-07-16 20:08:16] Clear theme cache
[2019-07-16 20:08:22] Extracting uploads...
[2019-07-16 20:08:40] Migrating uploads to S3...
[2019-07-16 20:08:46] Restore process was cancelled!
[2019-07-16 20:08:46] Trying to rollback...
[2019-07-16 20:08:46] Rolling back...
[2019-07-16 20:08:47] Cleaning stuff up...
[2019-07-16 20:08:47] Removing tmp '/var/www/discourse/tmp/restores/default/2019-07-16-200516' directory...
[2019-07-16 20:08:48] Unpausing sidekiq...
[2019-07-16 20:08:48] Marking restore as finished...
コマンドラインで discourse restore BACKUP_FILENAME を実行すると、より多くの出力が表示されますか?
次はこれを確認して、ご報告いたします。ありがとうございます。
以下は、コマンドラインで discourse restore BACKUP_FILENAME を実行した後の出力です。ご意見・フィードバックをいただければ幸いです。ありがとうございます!
一般ユーザー向けの送信メールを無効化中...
イモージキャッシュをクリア中...
読み取り専用モードを無効化中...
テーマキャッシュをクリア中
アップロードファイルを抽出中...
アップロードファイルを S3 へ移行中...
デフォルトが既に移行済みか確認中...
9474 件中 524 件のアップロードファイルが S3 へ移行されていません。S3 移行がデータベース 'default' で失敗しました。
321 件の投稿が新しい S3 アップロード URL へ再マッピングされていません。S3 移行がデータベース 'default' で失敗しました。
'default' で欠落しているアップロードファイルを検索中
欠落しているアップロードファイルを修正中:
..........................................................................................................
116 件の投稿用アップロードファイルが欠落しています。
116 件のアップロードファイルが欠落しています。
116 件中 106 件は旧方式のアップロードファイルです。
83342 件の投稿のうち 98 件に影響があります。
rake posts:missing_uploads で 98 件の問題が検出されました。S3 移行がデータベース 'default' で失敗しました。
再レンダリングが必要な投稿はありません
'default' のアップロードファイルを S3 へ移行中...
一部のアップロードファイルが新しい方式へ移行されませんでした。Rails コンソールで以下のコマンドを実行してください
SiteSetting.migrate_to_new_scheme = true
Jobs::MigrateUploadScheme.new.execute(nil)
復元プロセスがキャンセルされました!
ロールバックを試行中...
ロールバック中...
後処理中...
一時ディレクトリ '/var/www/discourse/tmp/restores/default/2019-07-22-172918' を削除中...
Sidekiq の一時停止を解除中...
復元を完了としてマーク中...
'system' に対して復元の終了を通知中...
完了!
[FAILED]
復元完了。
この件について、修正が実施されたか確認させてください。ありがとうございます!
gerhard
(Gerhard Schlager)
2019 年 7 月 29 日午後 10:14
9
いいえ、まだ修正されていません。ただし、回避策として、バックアップを作成する前に一時的に enable_s3_uploads サイト設定を無効にすることができます。
この課題に対する長期的な解決策についてフォローアップいたします。ありがとうございます!
これは解決しましたか?新しいサーバーへの移行時に同じ問題が発生しています。回避策を試してみます。
私もまさにこの問題に遭遇したと確信しています。これはバグとしてマークすべきだと思います。
(もし別問題であれば、新しいトピックに移動させてください)
バックアップの復元が機能することはかなり重要です。
管理 UI でバックアップ名の横にある Restore をクリックして失敗した場合、その理由が明確でないことに注意してください。以下のような表示になります:
...
Migrating uploads to S3...
Restore process was cancelled!
...
コマンドラインから復元を完了させると、より詳細な情報が得られます:
discourse enter app
discourse restore example-net-2020-01-02-033557-v20191219112000.tar.gz
...
Reconnecting to the database...
Reloading site settings...
Disabling outgoing emails for non-staff users...
Clearing emoji cache...
Disabling readonly mode...
Clear theme cache
Extracting uploads...
Remapping uploads...
Remapping '//forum-example-net.s3.dualstack.eu-west-2.amazonaws.com/' to '/uploads/default/'
optimized_images=3
uploads=1
Migrating uploads to S3...
Checking if default already migrated...
6 of 12 uploads are not migrated to S3. S3 migration failed for db 'default'.
1 posts are not remapped to new S3 upload URL. S3 migration failed for db 'default'.
Looking for missing uploads on: default
0 post uploads are missing.
Please provide the following environment variables
- DISCOURSE_S3_BUCKET
- DISCOURSE_S3_REGION
and either
- DISCOURSE_S3_ACCESS_KEY_ID
- DISCOURSE_S3_SECRET_ACCESS_KEY
or
- DISCOURSE_S3_USE_IAM_PROFILE
Restore process was cancelled!
Trying to rollback...
Rolling back...
Cleaning stuff up...
Dropping function from the discourse_functions schema
Removing tmp '/var/www/discourse/tmp/restores/default/2020-01-06-222212' directory...
Unpausing sidekiq...
Marking restore as finished...
Notifying 'system' of the end of the restore...
Finished!
[FAILED]
Restore done.
uploads.rake の Please provide the following environment variables の直前に、環境変数をダンプするための簡易的なデバッグコードを追加しました:
puts "ENV: " + ENV.inspect
ENV には DISCOURSE_S3_* 変数が設定されていませんでした。
このデータが設定から取得されないことには、意味のある理由があるのでしょうか?
pfaffman
(Jay Pfaffman)
2020 年 1 月 6 日午後 11:51
14
S3にアップロードがある場合、データベースのみをバックアップすれば、アップロードが含まれないため失敗しないという考え方が一般的です。
その通りですが、バックアップにアップロードが含まれている場合、それは役立ちません。
はっきりさせておきますが、今すぐ私にとって決定的に重要なことではありません。問題のある行をコメントアウトして復元を完了することはできますが、他の人にとってはそうはいかないのです。
pfaffman
(Jay Pfaffman)
2020 年 1 月 6 日午後 11:57
16
同意します。また、すべてのアップロードを S3 に移行するのはかなり複雑な作業であり、S3 CDN が必要です。
gerhard
(Gerhard Schlager)
2020 年 1 月 9 日午後 9:23
17
DeanMarkTaylor:
これはバグとしてマークすべきだと思います。
これを bug に変換する必要はありません。この件は私の担当事項であり、すでに復元プロセスのリファクタリング、多数のテストの追加、および信頼性の向上に多額の時間を費やしています。S3 への復元が破綻する可能性をさらに低減し、管理 UI でより多くの情報を出力するために、いくつかの微調整を行います。
RGJ
(Richard - Communiteq)
2020 年 2 月 18 日午前 9:59
18
私の知る限り、バックアップ/リストア機能は再設計されましたが、この問題がまだ残っていることがわかりました。
enable s3 uploads が有効なバックアップを beta11 でリストアしようとすると、以下のように失敗します。
[2020-02-18 09:51:38] Restoring uploads, this may take a while...
[2020-02-18 09:51:38] EXCEPTION: Please provide the following environment variables:
- DISCOURSE_S3_BUCKET
- DISCOURSE_S3_REGION
and either
- DISCOURSE_S3_ACCESS_KEY_ID
- DISCOURSE_S3_SECRET_ACCESS_KEY
or
- DISCOURSE_S3_USE_IAM_PROFILE
[2020-02-18 09:51:38] /var/www/discourse/lib/file_store/to_s3_migration.rb:34:in `s3_options_from_env'
pfaffman
(Jay Pfaffman)
2020 年 2 月 18 日午後 1:26
19
S3 アップロードはデータベースで有効になっていますが、S3 バックアップは有効になっていないのですか?
RGJ
(Richard - Communiteq)
2020 年 2 月 18 日午後 1:58
20
その通り、これはアップロードの移行に関するものです。
復元されたデータベースに S3 アクセス認証情報が存在するため、環境変数としても指定する必要はありません。
環境変数を指定しても失敗します。
アップロードを復元しています。時間がかかる場合があります...
db8015 が既に移行済みか確認中...
206 件中 200 件のアップロードが S3 に移行されていません。S3 移行が db 'db8015' で失敗しました。
5 件の投稿が新しい S3 アップロード URL に再マップされていません。S3 移行が db 'db8015' で失敗しました。
再焼き直しが必要な投稿はありません。
'db8015' のアップロードを S3 に移行中...
ファイルを S3 にアップロード中...
- ローカルファイルの一覧取得
=> 21 ファイル
- S3 ファイルの一覧取得
. => 16 ファイル
- ファイルを S3 に同期中
.....................
データベース内の URL を更新中...
古い最適化画像を削除中...
ライトボックスを含むすべての投稿に再焼き直しフラグを立て中...
5 件の投稿が再焼き直しのためにフラグ付けされました
例外: 206 件中 183 件のアップロードが S3 に移行されていません。S3 移行が db 'db8015' で失敗しました。
/var/www/discourse/lib/file_store/to_s3_migration.rb:127:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:74:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:350:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:61:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:203:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:48:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:30:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:58:in `run'
script/discourse:143:in `restore'
なぜ失敗しているのか見当もつきません。
ほとんどのアップロードは既に S3 にあったため、「206 件中 200 件のアップロードが S3 に移行されていません」および「206 件中 183 件のアップロードが S3 に移行されていません」というメッセージは誤りです。ローカルファイルが 21 件というのは正しい値で、S3 には約 200 件のアップロード(206 件の可能性もあります)が存在します。他の数値(183、16)については見当もつきません。
なぜ復元プロセスがさらに多くのアップロードを S3 へ移動しようとしているのかも不明です。バックアップからローカル画像を取得し、S3 上のアップロードはそのままにすべきではないでしょうか?それとも何か見落としているのでしょうか?
最終的には、データベースダンプ内の enable_s3_uploads 設定を false にハックして回避しましたが、その結果すべてのアップロードがローカルに再マップされてしまいました。いくつかの画像がまだローカルに残っていたため、どの画像を S3 に再マップすべきで、どの画像はそうでないのかを特定するのに多くの労力を要しました。
これらはすべて 2.4.0 beta11 での現象です。
gerhard
(Gerhard Schlager)
2020 年 2 月 18 日午後 8:38
21
ローカルへのアップロードと S3 に保存されたアップロードを混在させることはサポートされていません。はい、ご存知の通り、ローカルから S3 に切り替える際に既存のアップロードを S3 に移行しない場合、そのような状態になることはあり得ますが、それはまた別の話です。
バックアップの復元時には、アップロード URL に影響を与える変更が検出された場合、必ずアップロードの再マッピングが含まれます。これには、スタンドアロンとマルチサイト間の切り替え、ローカルアップロードと S3 間の切り替え、ならびに S3 および CDN 設定の変更が含まれます。すべての アップロードは、設定に基づいて正しい場所(ローカルまたは S3)に復元されます。
時折、さまざまな理由により、自動的な再マッピングや S3 への移行が失敗するバックアップに遭遇します。2.5 の開発サイクルの初期段階で、さらに多くの改善が行われることをお楽しみにしてください。