Не удалось выполнить миграцию в S3, поэтому невозможно восстановить из резервной копии

Поддержка Самостоятельное хостинг
1

Итак, у меня есть резервная копия Discourse с нашего начального сервера, и мы пытаемся перенести систему на новую.

К сожалению, возникли две проблемы:

  1. Во время восстановления сообщается, что 71 из 1073 файлов загрузок не перенесены в S3, из-за чего процесс восстановления критически завершается с ошибкой.

  2. При попытке исправить это на основном экземпляре путем повторной обработки (rebaking) постов и других действий система указывает, что некоторые файлы загрузок по-прежнему не перенесены в S3, даже когда я пытаюсь использовать механизм rake uploads:migrate_to_s3.

Есть ли какой-либо способ получить подробную информацию от migrate_to_s3 о том, какие именно файлы загрузок не перенесены, чтобы я мог исправить это вручную? Возможно, они ссылаются на нерабочее/неудачное хранилище S3, куда мы изначально загружали файлы. В тот момент всё пошло наперекосяк, и мы просто сменили механизм S3 (конечно, на MinIO), но на стороне AWS S3 всё ещё оставались старые данные. Которые, как мне кажется, я не смогу легко перенести в наш экземпляр MinIO.

Или, возможно, есть способ отключить проверку загрузок в S3 механизмом восстановления, поскольку я уже принудительно выполнил миграцию загрузок самостоятельно?

2

OK, понятно, разобрался после глубокого анализа БД. Похоже, это остатки (71 загрузка) из изначально давно отключенной среды S3 (или, в данном случае, доступной, но не основной среды S3, так как её использование было бы экономически нецелесообразным).

В итоге сделал следующее:

С исходного сервера:

  1. ./launcher enter app

  2. sudo -u postgres psql discourse

  3. SELECT url FROM uploads WHERE url NOT LIKE '%ExpectedS3DomainGoesHere%
    (замените ExpectedS3DomainGoesHere на фактический URL, используемый в вашей конфигурации S3)
    Это позволит получить URL-адреса для дальнейшей работы, так как нам нужно выполнить несколько действий.

  4. Если URL-адреса относятся к старым бакетам на других доменах, используйте клиент Amazon S3 (или клиент вашего бэкенда хранилища S3) и:
    a. Синхронизируйте бакеты с неожиданными URL-адресами (если они доступны) в локальное хранилище.
    b. Синхронизируйте элементы из локального хранилища в новый бакет.

  5. discourse remap OLD-URL-FROM-DB NEW-URL-FROM-DB
    Хотя в этой теме предлагалось использовать DbHelper.remap, функция remap из Discourse сработала отлично.

  6. Убедитесь, что данные мигрированы.
    rails uploads:migrate_to_s3

  7. Время пересоздания (rebake)!
    rails posts:rebake

  8. Снова создайте резервную копию сайта на исходной машине/сервере. Скачайте последнюю версию.

С нового целевого сервера:

  1. Настройте Discourse как обычно, скопируйте app.yml и другие файлы с исходного сервера на новый сервер в /var/discourse/containers/, чтобы убедиться, что пересборка затрагивает необходимые плагины и т. д.
    Однако, если вы работаете с локальными резервными копиями, обязательно закомментируйте любые записи DISCOURSE_BACKUP_LOCATION: s3 в файле app.yml. У меня возникли проблемы с S3: файлы резервных копий обрезались, поэтому я выбрал локальный подход для восстановления.

  2. Следуйте инструкциям по адресу Restore a backup from the command line, чтобы загрузить резервную копию на сервер и восстановить её. Включая шаги пересборки.

Мне было довольно больно это исправлять, но после глубокого анализа таблицы uploads в БД проблема была решена. Тем не менее, похоже, всё сработало, так что…

3

В таких ситуациях часто помогает временное отключение загрузки в S3 на исходном экземпляре перед созданием резервной копии. После восстановления вы можете снова включить S3.