アップロードの S3 移行ステップで復元プロセスがキャンセルされました

サポート
1

I’ve been running into issues trying to run a restore on our Staging Discourse instance. Staging is running v2.4.0.beta1 +36. Any idea where the breakdown might be or where to look? Thanks in advance!

Below is the end of the log output:

[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...
2

Is something wrong with your S3 config?

3

Do you see more output running discourse restore BACKUP_FILENAME from the command line?

4

I will check this next and report back. Thank you.

5

Below is the output after running discourse restore BACKUP_FILENAME from the command line. Any feedback is appreciated, thanks!

Disabling outgoing emails for non-staff users...

Clearing emoji cache...

Disabling readonly mode...

Clear theme cache

Extracting uploads...

Migrating uploads to S3...

Checking if default already migrated...

524 of 9474 uploads are not migrated to S3. S3 migration failed for db 'default'.

321 posts are not remapped to new S3 upload URL. S3 migration failed for db 'default'.

Looking for missing uploads on: default

Fixing missing uploads: 

..........................................................................................................

116 post uploads are missing.

116 uploads are missing.

106 of 116 are old scheme uploads.

98 of 83342 posts are affected.

rake posts:missing_uploads identified 98 issues. S3 migration failed for db 'default'.

No posts require rebaking

Migrating uploads to S3 for 'default'...

Some uploads were not migrated to the new scheme. Please run these commands in the rails console

SiteSetting.migrate_to_new_scheme = true

Jobs::MigrateUploadScheme.new.execute(nil)

Restore process was cancelled!

Trying to rollback...

Rolling back...

Cleaning stuff up...

Removing tmp '/var/www/discourse/tmp/restores/default/2019-07-22-172918' directory...

Unpausing sidekiq...

Marking restore as finished...

Notifying 'system' of the end of the restore...

Finished!

[FAILED]

Restore done.
6

That’s a known problem. I’ll fix it tomorrow.

8

Following up on this front to see if the fix has been implemented? Thanks!

9

No, it’s not fixed yet. But, as a workaround, you could temporarily disable the enable_s3_uploads site setting before creating the backup.

10

Following up on the long term fix for this challenge. Thanks!

11

Was this ever resolved? I’m getting the same issue when trying to migrate to a new server. I’m going to try the workaround.

12

This just bit me for a relatively large migration.

13

私もまさにこの問題に遭遇したと確信しています。これはバグとしてマークすべきだと思います。
（もし別問題であれば、新しいトピックに移動させてください）

バックアップの復元が機能することはかなり重要です。

管理 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_* 変数が設定されていませんでした。

このデータが設定から取得されないことには、意味のある理由があるのでしょうか？

14

S3にアップロードがある場合、データベースのみをバックアップすれば、アップロードが含まれないため失敗しないという考え方が一般的です。

15

その通りですが、バックアップにアップロードが含まれている場合、それは役立ちません。

はっきりさせておきますが、今すぐ私にとって決定的に重要なことではありません。問題のある行をコメントアウトして復元を完了することはできますが、他の人にとってはそうはいかないのです。

16

同意します。また、すべてのアップロードを S3 に移行するのはかなり複雑な作業であり、S3 CDN が必要です。

17

これを bug に変換する必要はありません。この件は私の担当事項であり、すでに復元プロセスのリファクタリング、多数のテストの追加、および信頼性の向上に多額の時間を費やしています。S3 への復元が破綻する可能性をさらに低減し、管理 UI でより多くの情報を出力するために、いくつかの微調整を行います。

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'
19

S3 アップロードはデータベースで有効になっていますが、S3 バックアップは有効になっていないのですか？

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 での現象です。

21

ローカルへのアップロードと S3 に保存されたアップロードを混在させることはサポートされていません。はい、ご存知の通り、ローカルから S3 に切り替える際に既存のアップロードを S3 に移行しない場合、そのような状態になることはあり得ますが、それはまた別の話です。

バックアップの復元時には、アップロード URL に影響を与える変更が検出された場合、必ずアップロードの再マッピングが含まれます。これには、スタンドアロンとマルチサイト間の切り替え、ローカルアップロードと S3 間の切り替え、ならびに S3 および CDN 設定の変更が含まれます。すべてのアップロードは、設定に基づいて正しい場所（ローカルまたは S3）に復元されます。

時折、さまざまな理由により、自動的な再マッピングや S3 への移行が失敗するバックアップに遭遇します。2.5 の開発サイクルの初期段階で、さらに多くの改善が行われることをお楽しみにしてください。