Не удалось использовать восстановление из NodeChef

Поддержка
1

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

вот лог

[2020-08-30 02:34:59] [STARTED]
[2020-08-30 02:34:59] Пользователь 'username' начал восстановление!
[2020-08-30 02:34:59] Установка статуса восстановления как «выполняется»...
[2020-08-30 02:34:59] Проверка существования директории /var/www/discourse/tmp/restores/default/2020-08-30-023459...
[2020-08-30 02:34:59] Копирование архива во временную директорию...
[2020-08-30 02:35:00] Распаковка архива, это может занять некоторое время...
[2020-08-30 02:35:01] Извлечение файла дампа...
[2020-08-30 02:35:07] Проверка метаданных...
[2020-08-30 02:35:07]   Текущая версия: 20200820232017
[2020-08-30 02:35:07]   Восстановленная версия: 20191209095548
[2020-08-30 02:35:07] Включение режима только для чтения...
[2020-08-30 02:35:07] Приостановка sidekiq...
[2020-08-30 02:35:07] Ожидание завершения выполнения задач Sidekiq (до 60 секунд)...
[2020-08-30 02:35:14] Создание отсутствующих функций в схеме discourse_functions...
[2020-08-30 02:35:15] Восстановление файла дампа..
2

Эта таблица не является частью Discourse, так что, полагаю, это особенность NodeChef?

В любом случае, вам нужно отредактировать файл резервной копии и удалить данные и ссылки на эту таблицу.

3

Кстати, просто из любопытства: у них было установлено довольно много плагинов. Мне нужно будет установить их на новую сборку, чтобы резервное копирование работало, или можно сделать это позже?

4

Восстановление не завершится неудачей без них, но обычно лучше иметь всё на своих местах в app.yml до запуска восстановления.

5

Моя резервная копия также создана в предыдущей версии, вызовет ли это какие-либо проблемы?

6

Что вы имеете в виду под предыдущей версией? Насколько она старая?

7

Нет, это не проблема — восстановление автоматически обновит его до текущей версии.
В данном случае настоятельно рекомендуется установить плагины перед восстановлением резервной копии.

8

Я смог найти только одно упоминание этого в файле .sql. Надеюсь, удаление выделенных частей решит проблему. (Полагаю, верхнее упоминание относится к public.spatial_ref_sys)

ye
ye1283×617 27.7 KB

Также, как заменить dump.sql внутри архива tar.gz на изменённую версию?

9 
# Сжать dump.sql и поместить его в ту же директорию, что и резервную копию
gzip dump.sql

# Скопировать файл резервной копии в файл с префиксом fixed-* (замените на имя вашего файла резервной копии)
cp backupfilename-2020-08-30-123456-v20200830123456.tar.gz fixed-backupfilename-2020-08-30-123456-v20200830123456.tar.gz

# Распаковать
gzip -d fixed-backupfilename-2020-08-30-123456-v20200830123456.tar.gz

# Удалить оригинальный dump.sql.gz из архива.
# Обратите внимание: на этом этапе имя файла резервной копии не содержит .gz.
tar f fixed-backupfilename-2020-08-30-123456-v20200830123456.tar --delete dump.sql.gz

# Добавить новый dump.sql.gz. Обратите внимание: на этом этапе имя файла резервной копии не содержит .gz.
tar fr fixed-backupfilename-2020-08-30-123456-v20200830123456.tar dump.sql.gz

# Снова сжать. Обратите внимание: на этом этапе имя файла резервной копии не содержит .gz.
gzip fixed-backupfilename-2020-08-30-123456-v20200830123456.tar
10

Спасибо, @RGJ, мой сайт снова работает как часы. Осталось только переустановить несколько плагинов.

Также огромное спасибо, @Falco, за помощь в выявлении проблемы.