Пожалуйста, подскажите, какой файл нужно отредактировать в резервной копии tar?
В архивах содержится файл dump.sql. Вам нужно его изменить, а затем запаковать изменённую версию обратно. Я также решил свои другие проблемы, изменив его — удалил несколько ошибочных пользовательских полей, которые вызывали сбои после входа в систему.
Спасибо.
Я попробую скачать резервную копию, распаковать её и изменить этот файл, следуя вашим инструкциям.
Довольно страшно, что для восстановления резервной копии приходится делать всё это.
Думаю, это ошибка нового релиза.
Но резервное копирование и восстановление являются краеугольными камнями плана аварийного восстановления.
Они должны быть максимально надёжными, и ошибка в этих процессах может иметь серьёзные последствия.
1 лайк
Что ж, мне удалось выполнить восстановление, не внося никаких изменений в файл резервной копии.
Я пробовал несколько раз, и, странно, один раз восстановление прошло без ошибок.
Меня выбросило из Discourse, и он не работал, пока я не создал приложение для пересборки лаунчера.
Но теперь всё работает корректно.
Странная проблема.
У меня всё ещё возникают проблемы с восстановлением форума из резервной копии. Прошло уже несколько недель, и функция восстановления из резервной копии, похоже, по-прежнему не работает.
Есть ли какое-либо исправление для этого?
Насколько я могу судить, приходится чередовать обновление, проверку форматирования таблиц, убеждение в том, что всё совпадает между исходником и хостом, и наблюдение за множественными сбоями. Это может сработать, а может и нет, если не внести небольшие правки в базу данных.
Я успешно мигрировал 2 из 3 сайтов, но вынужден уделять этому меньше часа в день, чтобы сохранить рассудок. Я уже начал обсуждать с клиентами возможные проблемы, которые могут возникнуть в будущем в подобных ситуациях. пожимает плечами
Я просто настаиваю на восстановлении, и мне удалось заставить это работать.
Ошибка указывает на столбец, которого не существует в таблице профиля пользователя.
Однако, скорее всего, это ошибка тайм-аута или что-то подобное на стороне базы данных, возможно, баг в PostgreSQL. Если столбец отсутствует, он не создается автоматически при повторной попытке восстановления.
Джаромир утверждает, что изменение скрипта решает проблему.
Похоже, что никто из разработчиков Discourse здесь не обратил внимания на эту проблему, но это странная и очень тревожная ошибка, поскольку она влияет на ваш план аварийного восстановления.
Возможно, эта тема осталась незамеченной среди других.
Это не осталось незамеченным. Завтра я займусь этим в первую очередь.
Кроме того, я приступаю к улучшению процессов резервного копирования и восстановления, поскольку никому не стоит беспокоиться об этом в случае катастрофы или при простой миграции на новый сервер.
11 лайков
Отлично. Спасибо.
Рада это слышать.
Спасибо, Герхард. Не знаю, интересует ли вас это сейчас, но у меня тоже возникли проблемы с сайтом, использующим PG 11 на GCP. Возможно, стоит проверить это, так как это может повлиять на будущий переход на PG 12, который, как я понимаю, должен состояться этой осенью.
Я только что обновил два экземпляра, которые используют общий бакет резервных копий S3. Я выполнил резервное копирование на одном из них и попытался восстановить данные на другом, но получил ошибку:
Нет миграции с номером версии 20191007140446.
PostgreSQL 11 и 12 в настоящее время не поддерживаются.
4 лайка
Хорошо, я установил последнюю версию Discourse (tests-passed) на Droplet, и восстановление резервных копий (включая загрузки, без использования S3 для загрузок) прошло без проблем.
Если у вас всё ещё возникают проблемы при восстановлении, выполните следующие действия:
-
Пересоберите контейнер:
cd /var/discourse git pull ./launcher rebuild app -
Восстановите резервную копию через веб-интерфейс или командную строку:
cd /var/discourse ./launcher enter app discourse enable_restore discourse restore <filename>
Если это не сработает, пожалуйста, укажите версию файла резервной копии, которую вы пытаетесь восстановить, а также сообщение об ошибке, которое вы видите в процессе восстановления.
6 лайков
Обе версии сайтов — 2.4.0.beta6 (8fc0cc9aaa). Резервные копии (но не загрузки) хранятся в S3.
discourse restore возвращает:
Starting restore: wonderful-community-2019-10-10-184822-v20191007140446.tar.gz
[STARTED]
'system' has started the restore!
Marking restore as running...
Making sure /var/www/discourse/tmp/restores/default/2019-10-10-211121 exists...
Downloading archive to tmp directory...
Unzipping archive, this may take a while...
EXCEPTION: Compression::Strategy::ExtractFailed
/var/www/discourse/lib/compression/gzip.rb:49:in `block in extract_file'
/var/www/discourse/lib/compression/gzip.rb:45:in `open'
/var/www/discourse/lib/compression/gzip.rb:45:in `extract_file'
Конечно, и я думаю, что этот сайт в любом случае будет доволен прямыми резервными копиями базы данных в GCP, но в какой-то момент Сэм сказал, что он использует PG 11 на своём тестовом сайте, и что ему было бы интересно узнать о проблемах с PG11.
@pfaffman Пожалуйста, увеличьте настройку сайта decompressed_file_max_size_mb (она скрыта). По умолчанию она сейчас установлена на 1 ГБ.
У меня уже готов PR для увеличения значения по умолчанию до 100 ГБ, но он ещё не был принят:
7 лайков
Спасибо, @Roman. Ну, эта проблема решена.
Но теперь у меня куча ошибок invalid command \N (они заполнили буфер, прежде чем я успел увидеть, что было до них), но, возможно, вам нужно знать вот это:
ERROR: syntax error at or near "Shiny"
LINE 1: Shiny contest submission 2019-01-07 20:00:05.570573 2019-01-...
^
EXCEPTION: psql failed
/var/www/discourse/lib/backup_restore/restorer.rb:324:in `restore_dump'
/var/www/discourse/lib/backup_restore/restorer.rb:75:in `run'
Да, я считаю, что это вызвано PG11.
2 лайка
Если бы это был экземпляр pg11, я бы согласился! Но это стандартная установка из двух контейнеров.
Подождите! Есть несоответствие версий.
root@community:/var/discourse# ./launcher enter data root@staging-data:/# psql --version
psql (PostgreSQL) 10.7 (Ubuntu 10.7-1.pgdg16.04+1)
Тот, на который я восстанавливаю, — версии 10.9! Я уверен, что дело в этом. (Кажется, pg11 падает аналогично, но там я пытаюсь восстановить на том же экземпляре).
Завтра я обновлю контейнеры данных и сообщу вам. Спасибо за помощь.
3 лайка
Что ж, я обновил оба до версии 10.10 (используя стандартные шаблоны данных), но всё равно получил сообщения об invalid command.
Когда начались ошибки invalid command, я принудительно завершил скрипт восстановления. Последующие попытки восстановления (чтобы получить первую ошибку до появления сообщений invalid command) привели к следующему:
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "theme_fields" does not exist
Затем я выполнил rake db:migrate на обоих экземплярах, снова создал резервные копии, и восстановление прошло успешно. Возможно, где-то по пути было упущено какое-то миграционное обновление?
(после изменения упомянутого выше параметра — вот полные инструкции для тех, кто может в них нуждаться в крошечный промежуток времени, прежде чем они станут ненужными)
./launcher enter app
rails c
SiteSetting.decompressed_file_max_size_mb=1000000
1 лайк
У меня снова не удалось завершить процесс. В обоих случаях версия 2.4.0.beta6 (одна из них 2c011252f1, другая, возможно, немного новее).
Я выполняю восстановление через S3. Пробовал как с загрузками, так и без них. Оба варианта казались рабочими, но затем завершались с ошибкой, как здесь:
...
COPY 11871
COPY 3689
COPY 0
COPY 36550
COPY 0
COPY 14736
/usr/local/bin/discourse: строка 2: 3232 Убит RAILS_ENV=production sudo -H -E -u discourse bundle exec script/discourse "$@"
Это единственное сообщение, которое вы получаете?
А что, если попробовать убрать любую зависимость от S3 и сначала скопировать файл резервной копии на локальный диск?
@pfaffman, стоит отметить, что две (или три) проблемы восстановления, которые вы опубликовали в этой теме, не являются проявлениями той ошибки, ради которой эта тема изначально создавалась (проблема PG::UndefinedColumn: ERROR). Возможно, вам стоит открыть для них новые темы, так как это явно разные проблемы.
4 лайка