Если я правильно понимаю, у вас не возникло проблем с выполнением предыдущих шагов: вы создали/отредактировали import.yml рядом с app.yml, пересобрали контейнер import, и теперь вы даже не можете в него зайти. Так? Это действительно странно!
Что возвращает эта команда? ls -l /var/discourse/containers
Всё осталось прежним: app.yml и import.yml (плюс файл-резервная копия app.yml).
Возможно, возникли «проблемы», так как я пытаюсь установить это на Lightsail с 1 ГБ ОЗУ (изначально 940 МБ, а после обновления Ubuntu становится «921 МБ»). Я использовал официальную установку, и была установлена версия вроде 3.3.* beta-что-то (в то время как в Вики указано, что 3.2 — самая последняя стабильная версия). Установка занимает 1 час 15 минут – 1 час 20 минут с 4 ГБ файла подкачки. Команда «launcher rebuild import» выполняется около 2 часов.
Могло ли что-то быть некорректно прервано из-за нехватки памяти?
Кстати, будут ли файлы резервных копий из настройки с 2 ГБ ОЗУ читаемы в настройке с 1 ГБ ОЗУ?
Удалось ли это? После пересборки контейнер должен быть запущен.
Вы не можете войти в контейнер, если он не запущен (./launcher start import)
Скорее всего, именно так. Здесь есть несколько тем, связанных с нехваткой памяти/файла подкачки и неудачной пересборкой — обычно другого выхода нет, кроме как увеличить объём оперативной памяти или файла подкачки.
Я не эксперт в этом вопросе, но надеюсь, кто-то сможет дать вам более подробную информацию.
Похоже, что проблема действительно в оперативной памяти. На Lightsail с 2 ГБ ОЗУ и 2 ГБ диска чистая установка прошла примерно в 3,5–4 раза быстрее, а пересборка контейнера импорта — примерно в 10 раз быстрее (или даже ещё быстрее).
Тем не менее, я боюсь, что скрипт импорта может не работать с phpBB 3.3.3. В любом случае, я пробовал дважды с одинаковым результатом: из примерно 10 категорий был импортирован только одно слово из одного названия категории, и оно появилось как одна пустая «категория». Дамп базы данных MySQL довольно небольшой — 2,66 МБ. Все префиксы таблиц соответствуют требованиям. Никаких изображений, смайликов и т. п. нет.
В итоге ни форумов, ни категорий форумов, ни сообщений импортировано не было, зато все (несколько сотен) пользователей были импортированы корректно вместе со своей статистикой.
Кажется, что обновление до phpBB 3.3.3 внесло изменения, связанные с используемой версией MySQL, но поскольку здесь речь идёт о файле дампа, в конечном счёте это не должно иметь значения.
Есть ли какие-то идеи, что ещё можно проверить?
Вы имеете в виду, что для открытия/чтения/парсинга этого текстового файла размером 2,6 МБ требуется 4 ГБ? Вы разработчик Discourse? Двоичный исполняемый файл для чтения этого дампа (извлечение всех данных, используемых Discourse) и сохранения их в любой другой формат, по моему мнению, должен занимать около 200 КБ с буфером, скажем, 100 КБ (без необходимости включать всю MariaDB для такого простого действия).
Я думаю, дело не в оперативной памяти. Процедура работала быстро и отображала прогресс импорта для импортируемых таблиц. Она не «завершалась». Таблица пользователей находится в конце дампа, после тем и т. д.
Я хотел повторить это, экспериментируя с копированием/вставкой таблицы пользователей в начало и выполнением тех же шагов из вышеупомянутого руководства/страницы (также с дампом, созданным phpMyAdmin вместо phpBB), но теперь Discourse отказывается запускать процедуру, пытаясь подключиться удалённо, хотя данные для подключения не добавлялись.
Я пересобрал контейнер импорта, но, возможно, сначала нужно что-то удалить?
Я зарабатываю на жизнь поддержкой Discourse и выполнил больше миграций, чем могу сосчитать, — наверное, около сотни или даже больше. 2 ГБ, скорее всего, хватит, особенно если у вас всего несколько тысяч тем и пользователей, но раз вам это нужно лишь на короткое время, дополнительная оперативная память не стоит дорого и лишней не будет. Я согласен, что, вероятно, проблема не в этом.
Когда скрипт выполнялся, он проходил по категориям, пользователям, темам и сообщениям?
Скрипт пропускает уже импортированные данные и создаёт пользовательские поля, чтобы в будущем их не обрабатывать повторно. Поэтому для повторного запуска необходимо очистить базу данных Discourse. Поскольку вы утверждаете, что ничего не было импортировано, непонятно, действительно ли это требуется. Похоже, что либо данные были импортированы, но вы их по какой-то причине не видите, либо скрипт не сработал, потому что не нашёл данные, и тогда нужно как-то модифицировать скрипт. Ни в одном из этих случаев не требуется очистка базы данных.
Так как вы говорите, что ничего не импортировалось
Не совсем так:
«Все (несколько сотен) пользователей были импортированы корректно вместе со своей статистикой»
Я попытался снова пересобрать контейнер. Те же настройки. Я ничего не менял, и после шага:
import_phpbb3.sh # внутри Docker-контейнера
скрипт теперь выводит:
/var/www/discourse/vendor/bundle/ruby/3.2.0/gems/mysql2-0.5.6/lib/mysql2/client.rb:97:in `connect’: Unknown database ‘phpbb’ (Mysql2::Error)
Возможно, всё ещё остались какие-то ранее использованные временные файлы, которые нужно удалить?
В итоге я использовал дамп из phpMyAdmin. Есть ли какой-либо пример (или более подробная спецификация), как создать секции маппинга в файле настроек импорта settings.yml?
Моя таблица php_forums выглядит следующим образом:
Кажется, что какие бы идентификаторы я ни использовал и указываю ли я также секцию “new_categories: ”, сообщение, генерируемое контейнером импорта, корректно:
создание новых категорий
11 / 11 (100.0%) [2803 элементов/мин] n]
создание категорий
11 / 11 (100.0%) [2704 элементов/мин]
Но создаются две основные категории (которые в phpBB были “форумами” с parent_id 0) и по одной пустой подкатегории в каждой из них. Процедура импортирует все сообщения, но все они оказываются “сиротами”.
Что ж, на самом деле я сделал шаг вперёд, исправив свою ошибку: я просто добавил комментарии в файл settings.yml в стиле C/C++ в конце строк. Это, apparently, помешало подфорумам быть «обработанными» (хотя ошибок не отображалось).
Я добавил категории и подкатегории как «новые» и сопоставил старые ID.
Тем не менее, все посты не прикреплены ни к какой категории. Хранятся ли такие темы в одной таблице Postgres? Как их можно удалить?
Я добавил несколько исправлений в файл phpbb_mysql.sql, по крайней мере, чтобы скрипт мог создать все исходные категории, но этого недостаточно.
При обработке тем/сообщений выводится длинный список вида:
Родительское сообщение [некоторый id] не существует. Пропуск [некоторый id]
и, разумеется, сообщения не импортируются.
Интересно, сможет ли кто-нибудь подтвердить, что стандартные скрипты не работают с таблицами phpBB 3.3.3?
В конце концов мне удалось использовать дамп phpBB 3.3.3, не определяя категории как новые и не прописывая все сопоставления в файле settings.yml.
При использовании исходного файла дампа phpBB_mysql.sql скрипт миграции завершается на этапе загрузки категорий и выводит ошибку: «пустое тело категории».
Это происходит, если поле «forum_desc» в таблице «phpbb_forums» для основных категорий форума (у которых нет родительских категорий) пустое.
После частичного импорта только первой категории остальные, по-видимому, оказываются повреждены.
Использование чистой установки и заполнение текстом полей в указанной таблице, похоже, решает эту проблему.
