在迁移上传至 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...
1 个赞
2

Is something wrong with your S3 config?

3

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

1 个赞
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.
5 个赞
6

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

8 个赞
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.

4 个赞
10

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

1 个赞
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.

3 个赞
12

This just bit me for a relatively large migration.

3 个赞
13

我很确定我也遇到了这个问题，我认为这应该被标记为错误。
（如果情况不同，请随时将其移至新的独立主题）

恢复备份能否正常工作至关重要。

请注意，在使用管理界面并点击备份名称旁边的 <kbd>Restore</kbd> 时，失败的原因并不明显，你会看到：

...
正在将上传文件迁移到 S3...
恢复过程已取消！
...

通过命令行完成恢复会提供更详细的信息：

discourse enter app
discourse restore example-net-2020-01-02-033557-v20191219112000.tar.gz
...
正在重新连接数据库...
正在重新加载站点设置...
正在为普通用户禁用外部邮件...
正在清除表情符号缓存...
正在禁用只读模式...
正在清除主题缓存
正在解压上传文件...
正在重新映射上传文件...
正在将 '//forum-example-net.s3.dualstack.eu-west-2.amazonaws.com/' 重新映射为 '/uploads/default/'
optimized_images=3
uploads=1
正在将上传文件迁移到 S3...
正在检查默认数据库是否已迁移...
12 个上传文件中有 6 个未迁移到 S3。数据库 'default' 的 S3 迁移失败。
1 个帖子未重新映射到新的 S3 上传 URL。数据库 'default' 的 S3 迁移失败。
正在 default 中查找缺失的上传文件

0 个帖子上传文件缺失。
  请提供以下环境变量
    - DISCOURSE_S3_BUCKET
    - DISCOURSE_S3_REGION
    以及以下任一选项
    - DISCOURSE_S3_ACCESS_KEY_ID
    - DISCOURSE_S3_SECRET_ACCESS_KEY
    或
    - DISCOURSE_S3_USE_IAM_PROFILE
恢复过程已取消！
正在尝试回滚...
正在回滚...
正在清理...
从 discourse_functions 架构中删除函数
正在删除临时目录 '/var/www/discourse/tmp/restores/default/2020-01-06-222212'...
正在取消暂停 sidekiq...
正在标记恢复为已完成...
正在通知 'system' 恢复结束...
完成！
[FAILED]
恢复完成。

我在 uploads.rake 中“请提供以下环境变量”之前添加了一点调试代码来输出环境变量：

puts "ENV: " + ENV.inspect

ENV 中没有任何 DISCOURSE_S3_* 变量被设置。

是否有合理的理由导致它不从设置中获取这些数据？

14

我认为这种观点是：如果你将文件上传到 S3，那么只需进行仅包含数据库的备份，这样就不会因为缺少上传文件而导致备份失败。

3 个赞
15

完全同意，但这对你手头包含上传文件的备份并没有什么帮助。

说明一下——目前这对我来说并非关键问题，我可以注释掉出错的行并完成恢复，但其他人做不到。

3 个赞
16

同意。将所有上传迁移到 S3 是一项相当复杂的任务，并且需要 S3 CDN。

1 个赞
17

无需将其转换为 #bug。这已在我的处理范围内，我已经花费了大量时间重构恢复流程，增加了大量测试并提升了其可靠性。我还会再做几处调整，以降低恢复至 S3 时出错的概率，并在管理界面中输出更多信息。

7 个赞
18

据我所知，备份/恢复功能已经过重构，但我刚刚发现这仍然是一个问题。
在 beta11 上尝试恢复一个启用了 enable s3 uploads 的备份时，仍然失败，错误信息如下：

[2020-02-18 09:51:38] 正在恢复上传内容，这可能需要一些时间...
[2020-02-18 09:51:38] 异常：请提供以下环境变量：
  - DISCOURSE_S3_BUCKET
  - DISCOURSE_S3_REGION
  以及以下任一选项：
  - DISCOURSE_S3_ACCESS_KEY_ID
  - DISCOURSE_S3_SECRET_ACCESS_KEY
  或
  - 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'
1 个赞
19

所以数据库中启用了 S3 上传，但未启用 S3 备份？

20

正确，这涉及上传迁移问题。

S3 访问凭据已存在于恢复的数据库中，因此无需再将其设置为环境变量。

提供环境变量同样会导致失败：

正在恢复上传内容，这可能需要一些时间...
正在检查 db8015 是否已迁移...
200 个上传内容中的 206 个尚未迁移到 S3。S3 迁移失败，数据库为 'db8015'。
5 篇帖子尚未重新映射到新的 S3 上传 URL。S3 迁移失败，数据库为 'db8015'。
没有帖子需要重新烘焙。
正在将 'db8015' 的上传内容迁移到 S3...
正在上传文件到 S3...
 - 列出本地文件
 => 21 个文件
 - 列出 S3 文件
. => 16 个文件
 - 将文件同步到 S3
.....................
正在更新数据库中的 URL...
正在删除旧的优化图片...
正在标记所有包含灯箱的帖子以进行重新烘焙...
5 篇帖子已被标记为需要重新烘焙
异常：206 个上传内容中的 183 个尚未迁移到 S3。S3 迁移失败，数据库为 '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 版本上。

1 个赞
21

不支持将本地上传与存储在 S3 上的上传混合使用。是的，我们知道，当有人从本地上传切换到 S3 但未将现有上传迁移到 S3 时，可能会出现这种情况，但这又是另一个故事了……

恢复备份时，如果系统检测到任何会影响上传 URL 的更改，总会重新映射上传。这包括在独立站和多站点之间切换、在本地上传和 S3 之间切换，以及 S3 和 CDN 设置的更改。所有上传都会根据设置（本地或 S3）恢复到正确的位置。

我们偶尔会遇到因各种原因导致自动重新映射和迁移到 S3 失败的备份。预计在 2.5 开发周期的早期，您将看到更多改进。

7 个赞