Аватары пропали после восстановления. Как их вернуть?

Поддержка
1

Я выполнил чистую установку Discourse и восстановил резервную копию, созданную в этот же вечер (используя интерфейс Discourse для создания и восстановления резервной копии).

Резервная копия включала базу данных и загруженные файлы.

После восстановления и пересборки приложения Discourse (что, как я предполагаю, было необходимо из-за изменений в конфигурации после чистой установки), возникла проблема.

Аватары всех пользователей, которые настраивали свои изображения профиля, были утеряны.

Полагаю, это связано с оптимизацией изображений; возможно, нужно выполнить какие-то дополнительные действия (помимо пересборки приложения через launcher) для их восстановления.

Однако я не смог найти, какой шаг был упущен.

Я нашёл тему, где люди сообщали об утере стандартных аватаров (тех, что поставляются с Discourse), но наш случай иной: у тех, кто не менял свой аватар (и не загружал изображение), буквенный аватар остался на месте.

ОБНОВЛЕНИЕ:

Я выполнил:
./launcher enter app
rake posts:rebake

Но это не помогло.

Возможно, это не posts:rebake?

2

@arinaf,

Странно, но сегодня со мной произошло то же самое на конфигурации с обратным прокси-сервером nginx, подключённым к unix-сокету. Всё работало идеально, кроме кастомных аватаров: они отображались как иконки (иконка человека), а аватары с буквами были в порядке.

Во время устранения неполадок я вернулся к стандартной конфигурации с двумя контейнерами (без фронтенда nginx и без unix-сокета), и проблема исчезла.

Затем я снова переключился на конфигурацию с обратным прокси-сервером nginx и unix-сокетом, и проблема вернулась.

Я в тупике… поэтому сделаю перерыв на некоторое время :slight_smile:

Очевидно, что данные в порядке, так как всё работает идеально без обратного прокси-сервера nginx, что странно, ведь без него всё работает отлично. LOL (раньше всё работало безупречно в обоих вариантах, и вдруг появилась эта странная проблема с аватарами…)

3

Это именно моя конфигурация, так как я запускаю другое ПО в контейнере Docker (блог Ghost).
У меня nginx работает как обратный прокси.

Очевидно, что восстановление резервных копий не так просто, как кажется.

Я делал ребейки, полагая, что проблема в том, что миниатюры не сохраняются, но это не помогло.

Попробую то, что вы посоветовали, чтобы подтвердить, связана ли проблема с обратным прокси (не понимаю, почему он может мешать, но мне нечего терять, попробовав).

4

Да… Я не думаю, что проблема связана с базой данных на стороне сервера, восстановлением БД или выполнением задач Rake.

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

Я отключусь от сети на 12 часов, поэтому вернусь позже и посмотрю, что у вас получилось на вашей настройке, @ariznaf.

5

Вы используете HTTPS вне контейнера?

Вы проверяли исходный код страницы, чтобы увидеть, какие URL-адреса используются для аватаров?

Похоже, что force_https не включен.

6

Я не могу сделать это прямо сейчас, так как мне придется начинать всё с нуля.

Я пытался скопировать все файлы (при выключенном Discourse на исходном сервере), но это тоже не сработало (проблемы с базой данных).

Я попробую начать заново: установлю чистый Discourse, а затем восстановлю резервную копию, созданную через Discourse.

7

Я проверю, спасибо.

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

Спасибо вам обоим.

8

Если вы не используете обратный прокси и целевая платформа настроена корректно, процесс обычно невероятно прост.

9

Хорошо, если бы не то, что в среднем времени происходило обновление самого Discourse или используемых вами плагинов (я использую лишь несколько официальных плагинов, предпросмотр тем и несколько компонентов). Каждый раз при попытке симулировать восстановление возникали какие-то проблемы.

Мне кажется, что система резервного копирования проста и понятна, но недостаточно надежна при переносе всего на другой сервер.
И она недостаточно гибкая.

Создание резервной копии занимает слишком много времени (для такого небольшого сайта полное резервное копирование составляет всего 3 ГБ).

На нашем старом форуме было более 100 ГБ данных; было бы невозможно сделать резервную копию такого большого форума с помощью текущей системы.

10

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

11

АХ, ОК.
Огромное спасибо.
Я не знал, что они перестраиваются в фоновом режиме.
Значит, нужно просто подождать.

Я уже начинал злиться, используя rake posts:rebuild и подобные команды.

Вы избавили меня от множества головных болей. Большое спасибо.

12

Вы можете ускорить этот процесс, перейдя на страницу /sidekiq/scheduled на вашем форуме и нажав кнопку «Запустить» рядом с задачей CreateMissingAvatars.

13

Вау, там в /sidekiq целый скрытый мир :slight_smile:

Я пробовал то, что вы предложили.

Но задача CreateMissingAvatars запланирована и запускается, однако завершается почти мгновенно — на её выполнение уходит всего несколько миллисекунд. Я также попытался запустить её вручную (через Trigger), но она снова завершается мгновенно с результатом OK.

Тем не менее, аватары всё ещё отображаются неверно.

Сейчас я использую свою исходную конфигурацию: Discourse слушает сокет, а nginx работает как обратный прокси.

Теперь я попробую убрать nginx и запустить Discourse напрямую на портах 80 и 443.

14

Привет, @ariznaf

Утром проснулся после 12 часов без интернета, переключился обратно на конфигурацию socket-only.yml — и всё снова работает как надо.

Так что, по крайней мере, в нашей части обширного «дискурсовселенной», в мире двух контейнеров с nginx как обратным прокси к unix-сокету, снова всё хорошо.

Мы перешли на конфигурацию с nginx в качестве фронтенда примерно за шесть часов до того, как была замечена аномалия, и всё было в порядке.

Исходя из этого полезного совета от @riking (как всегда, большое спасибо, Кейн):

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

Screen Shot 2020-04-17 at 9.06.09 AM

Моя лучшая гипотеза: когда мы переключились на nginx, мы не заметили никаких проблем, потому что множество изображений аватаров уже были закэшированы, а процесс регенерации ещё не завершился. Со временем кэш для этих изображений истёк, и аномалия начала проявляться.

Так что я отключился от сети (контейнер socket-only.yml продолжал работать в фоне, но бездействовал) на 12 часов, утром проснулся, и sidekiq за ночь совершил своё волшебство (здесь), как и сказал @riking (отличная поддержка, кстати, Кейн, на каждой теме здесь, на meta).

Этот сценарий, похоже, подтверждает предположение @riking.

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

Наши контейнеры сейчас выглядят так:

# ls -l containers
-rw-r--r-- 1 discourse root 1124 Apr 15 11:29 data.yml
-rw-r--r-- 1 discourse root 3939 Apr 16 07:45 socket-only.yml
-rw-r--r-- 1 discourse root 3784 Apr 16 07:28 socket.yml
-rw-r--r-- 1 discourse root 3921 Apr 15 11:50 web-only.yml

Мне нравится, что даже когда возникает проблема, например эта аномалия регенерации аватаров, мы можем легко переключаться между socket-only.yml и web-only.yml.

В данном случае мы вернулись к web-only (во время регенерации), а затем снова переключились после завершения процесса (поскольку все контейнеры продолжали работать). При пересборке контейнеров мы можем очень легко переключаться между этими конфигурациями.

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

Сайдбар (редакторское замечание):

Конечно, это выше моего уровня на meta, но я считаю, что базовая конфигурация из двух контейнеров (без обратного прокси) должна быть по умолчанию, поскольку она очень проста в настройке, и мы получаем от неё гораздо больше пользы, чем любые предполагаемые «штрафы» за наличие двух файлов yml.

15

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

Как уже отмечалось, мы потеряли аватары и некоторые другие мелкие элементы.

Я пытался следовать инструкциям от @riking, но безрезультатно.

Я также пробовал обновить аватары, принудительно запустив процесс их генерации. Однако процесс завершался со статусом «OK» за несколько миллисекунд, но аватары так и не были созданы.

Поскольку нам нужно было срочно перенести контент, я остановил форум на старом сервере, скопировал все содержимое контейнеров и общих директорий с помощью tar, установил Discourse на новый сервер (без первоначальной настройки), перенёс туда общие директории и директории контейнеров, а затем пересобрал приложение.

Теперь всё работает на новом сервере.

Восстановление из резервной копии оказалось более проблематичным, чем ожидалось (хотя, судя по инструкциям, всё должно быть просто: переустановить и восстановить через интерфейс).

Мне предстоит разобраться, что именно идёт не так при восстановлении, и как гарантировать, что система запустится даже при восстановлении из старой резервной копии, когда версия Discourse на сервере значительно новее той, при которой была создана резервная копия.

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

Однако, когда вы всё же находите нужное, оно оказывается именно там, где должно быть, и реализовано очень изящно.

Проблемы у нас возникают только при восстановлении из резервной копии.
Иногда также возникают сложности из-за активного использования кэширования.

Discourse при первом запуске в браузере загружается довольно долго, но после этого работает очень быстро, поскольку большая часть обработки происходит на вашем устройстве, а система активно использует кэш (аватары, изображения, CSS и т. д.).
Приложение не запрашивает информацию, которая уже есть на вашем компьютере, что значительно снижает нагрузку на сервер (по крайней мере, так кажется исходя из моего опыта).

Когда я пытаюсь перенести форум с одного сервера на другой или переустановить Discourse с нуля, в браузере всё ещё отображается старый контент, даже если обновить страницу.

Избавиться от этого удалось только после очистки истории браузера.
Это занимало у меня много времени и вызывало путаницу.

Кстати, сохраняются ли аватары, если в резервной копии выбраны сохранённые миниатюры?
Как вы думаете, лучше ли их сохранять? Наш форум не очень большой, но архивирование 36 000 изображений заняло довольно много времени.

16

Привет, @ariznaf,

Наше полное резервное копирование имеет такой же размер — около 3 ГБ в сжатом виде (gzipped).

Пока я не столкнулся ни с одной из проблем, которые вы упомянули в своём посте (не выше, #13).

Вы восстанавливаете данные через командную строку или через интерфейс?

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

Отличные новости. Поздравляю.

17

Спасибо за ваш интерес.

Я следовал инструкциям в руководствах, используя интерфейс. Я не знаю, как восстановить данные из командной строки (резервные копии, созданные через интерфейс Discourse).

Позвольте мне объяснить:

Мне пришлось перенести сервер с a.domain.com на b.domain.com.
Форум Discourse доступен через HTTPS с использованием пользовательского SSL (у нас есть сертификаты SSL для всего домена).
Discourse установлен с использованием сокета, и параметр HOST NAME был установлен как a.domain.com.
Мы настроили nginx в качестве обратного прокси для постоянного перенаправления трафика http (порт 80) на https (порт 443), а https (порт 443) работает как обратный прокси для трафика https, перенаправляя его на сокет, на котором слушает Discourse.

У меня была резервная копия (через интерфейс) с a.domain.com в бакете S3, содержащая базу данных и загруженные файлы, но не миниатюры (около 3 ГБ).

Я установил nginx и скопировал файл конфигурации с a.domain.com, изменив имя хоста с a.domain.com на b.domain.com.

Я установил Discourse, клонировав репозиторий с GitHub (как рекомендовано в руководстве по установке за 30 минут).
Затем я запустил настройку Discourse (с остановленным nginx) и настроил параметр HOSTNAME как b.domain.com.

Я получил доступ к новой установке на b.domain.com, войдя как администратор.
Через интерфейс я настроил резервное копирование для доступа к бакету S3, активировал возможности восстановления для администратора и восстановил последнюю резервную копию.

После этого вы были разлогинены из Discourse, так как появились новые пользователи, настройки и т. д.

Вернувшись к командной строке, я отредактировал файл app.yml и скопировал конфигурацию с оригинального сервера (a.domain.com), изменив только имя хоста на b.domain.com.

Затем я выполнил команду ./launcher rebuild all, а после завершения запустил nginx.

Я получил доступ к форуму Discourse, но аватары были потеряны, и возникли другие проблемы с миниатюрами изображений.

18

Спасибо за такие подробные пояснения, @ariznaf.

Честно говоря, я не поклонник облачных хранилищ, таких как S3, поэтому, думаю, лучше мне отложить любые дальнейшие идеи, раз мы не «пользователи S3»…

19

Вы говорите, что аватары потеряны, но вы проверяли исходный код страницы, чтобы увидеть, откуда они запрашиваются?

Они всё ещё находятся в S3?

Почему вам потребовалось изменить поддомены?

Чтобы прояснить ситуацию: вы изменили и физический сервер, и DNS-адрес?

20

Рикинг говорит, что системе нужно пересобрать миниатюры. Но задача, похоже, уже была завершена.

Я попробую снова. Сейчас я решил это другим способом.

В S3 сохраняются только резервные копии; изображения и загруженные файлы хранятся локально.

Однако мне нужно провести тесты восстановления, чтобы понять, в чём проблема.
Я проверю, откуда система пытается получить изображение.

Но было показано изображение с белым силуэтом, так что это не битая ссылка; система, вероятно, заменила его, потому что у него нет миниатюры.