Процесс восстановления отменен на этапе миграции загрузок в S3

Поддержка
1

У меня возникли проблемы при попытке выполнить восстановление на нашем тестовом экземпляре Discourse. Тестовый сервер работает на версии 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] Миграция базы данных...
[2019-07-16 20:08:16] Переподключение к базе данных...
[2019-07-16 20:08:16] Перезагрузка настроек сайта...
[2019-07-16 20:08:16] Отключение исходящих писем для пользователей, не являющихся сотрудниками...
[2019-07-16 20:08:16] Очистка кэша эмодзи...
[2019-07-16 20:08:16] Отключение режима только для чтения...
[2019-07-16 20:08:16] Очистка кэша тем
[2019-07-16 20:08:22] Извлечение загруженных файлов...
[2019-07-16 20:08:40] Перемещение загруженных файлов в S3...
[2019-07-16 20:08:46] Процесс восстановления был отменён!
[2019-07-16 20:08:46] Попытка отката...
[2019-07-16 20:08:46] Выполнение отката...
[2019-07-16 20:08:47] Очистка временных данных...
[2019-07-16 20:08:47] Удаление временной директории '/var/www/discourse/tmp/restores/default/2019-07-16-200516'...
[2019-07-16 20:08:48] Возобновление работы sidekiq...
[2019-07-16 20:08:48] Пометка восстановления как завершённого...
2

Что-то не так с вашей конфигурацией S3?

3

Вы видите больше выводов при запуске discourse restore BACKUP_FILENAME из командной строки?

4

Я проверю это следующим и отчитаюсь. Спасибо.

5

Ниже приведен вывод после выполнения команды discourse restore BACKUP_FILENAME в командной строке. Любая обратная связь будет полезна, спасибо!

Отключение исходящей почты для пользователей, не являющихся сотрудниками...

Очистка кэша эмодзи...

Отключение режима только для чтения...

Очистка кэша темы

Извлечение файлов...

Миграция файлов в S3...

Проверка, была ли выполнена миграция по умолчанию...

524 из 9474 файлов не были мигрированы в S3. Миграция в S3 не удалась для базы данных 'default'.

321 сообщение не было переадресовано на новый URL загрузки в S3. Миграция в S3 не удалась для базы данных 'default'.

Поиск отсутствующих файлов на: default

Исправление отсутствующих файлов: 

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

Отсутствуют файлы для 116 сообщений.

Отсутствуют 116 файлов.

106 из 116 — это файлы по старой схеме.

Затронуто 98 из 83342 сообщений.

rake posts:missing_uploads выявил 98 проблем. Миграция в S3 не удалась для базы данных 'default'.

Нет сообщений, требующих повторной обработки

Миграция файлов в S3 для 'default'...

Некоторые файлы не были мигрированы на новую схему. Пожалуйста, выполните следующие команды в консоли 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]

Восстановление завершено.
6

Это известная проблема. Я исправлю её завтра.

8

Напоминаю по этому вопросу: удалось ли внедрить исправление? Спасибо!

9

Нет, это ещё не исправлено. Однако в качестве временного решения вы можете отключить настройку сайта enable_s3_uploads перед созданием резервной копии.

10

Продолжаем работу над долгосрочным решением этой проблемы. Спасибо!

11

Это когда-либо было решено? У меня возникает та же проблема при попытке миграции на новый сервер. Я попробую обходной путь.

12

Это только что подвело меня при относительно крупной миграции.

13

Я почти уверен, что столкнулся с этой же проблемой. Думаю, это стоит пометить как баг.
(Если это другая ситуация, не стесняйтесь перенести обсуждение в отдельную тему)

Восстановление из резервных копий — довольно важная функция.

Обратите внимание: при использовании административного интерфейса и нажатии кнопки Restore рядом с именем резервной копии причина сбоя неочевидна. Вы видите:

...
Миграция загрузок в 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...
Проверка, была ли уже выполнена миграция по умолчанию...
6 из 12 загрузок не были перенесены в S3. Миграция в S3 не удалась для БД 'default'.
1 пост не был перепривязан к новому URL загрузки в S3. Миграция в S3 не удалась для БД 'default'.
Поиск отсутствующих загрузок в: 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 прямо перед строкой “Please provide the following environment variables”, чтобы вывести значения переменных окружения:

puts "ENV: " + ENV.inspect

В ENV не было установлено ни одной переменной DISCOURSE_S3_*.

Есть ли веская причина, по которой эти данные не подтягиваются из настроек?}

14

Полагаю, подразумевается, что если у вас есть загрузочные файлы в S3, то вы будете выполнять резервное копирование только базы данных, и оно не завершится неудачей, так как файлы загрузок в него не включены.

15

Полностью согласен, но это не помогает, когда у вас есть резервная копия, включающая загруженные файлы.

Чтобы прояснить: для меня сейчас это не критически важно — я могу закомментировать проблемные строки и завершить восстановление, но другие пользователи не смогут этого сделать.

16

Согласен. К тому же перенос всех загрузок в S3 — довольно сложная задача, требующая CDN для S3.

17

Нет необходимости превращать это в bug. Это в моей зоне ответственности, и я уже потратил огромное количество времени на рефакторинг процесса восстановления, добавление множества тестов и повышение его надёжности. Я внесу ещё несколько правок, чтобы сделать восстановление в S3 менее подверженным сбоям и вывести больше информации в административном интерфейсе.

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

Значит, загрузка в S3 включена в базе данных, но резервные копии в S3 нет?

20

Верно, речь идет о миграции загрузок.

Учетные данные доступа S3 присутствуют в восстановленной базе данных, поэтому нет необходимости дублировать их в переменных окружения.

Передача переменных окружения также приводит к ошибке:

Восстановление загрузок, это может занять некоторое время...
Проверка, была ли уже выполнена миграция для db8015...
200 из 206 загрузок не перенесены в S3. Миграция в S3 не удалась для БД 'db8015'.
5 постов не переназначены на новый URL загрузки S3. Миграция в S3 не удалась для БД 'db8015'.
Постов, требующих перекомпиляции, нет.
Миграция загрузок в S3 для 'db8015'...
Загрузка файлов в S3...
 - Список локальных файлов
 => 21 файл
 - Список файлов в S3
. => 16 файлов
 - Синхронизация файлов с S3
.....................
Обновление URL в базе данных...
Удаление старых оптимизированных изображений...
Пометка всех постов с лайтбоксами на перекомпиляцию...
5 постов помечены на перекомпиляцию
ИСКЛЮЧЕНИЕ: 183 из 206 загрузок не перенесены в 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, поэтому сообщения «200 из 206 загрузок не перенесены в S3» и «183 из 206 загрузок не перенесены в 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.