На форуме, который я перенёс, ранее была установлена xengallery, поэтому мне пришлось внести следующие изменения, так как таблицы xfgallery больше не существует.
def get_xf_sql(type, id)
case type
when :gallery
return "SELECT NULL WHERE 1=0;"
when :attachment
<<-SQL
SELECT a.attachment_id, a.data_id, d.filename, d.file_hash, d.user_id
FROM #{TABLE_PREFIX}attachment AS a
INNER JOIN #{TABLE_PREFIX}attachment_data d ON a.data_id = d.data_id
WHERE attachment_id = #{id}
AND content_type = 'post'
SQL
end
end
При выполнении вышеуказанной команды возникает следующая ошибка. Я проверил файл Gemfile, и он содержит только одну строку — gem ‘mysql2’.
This Gemfile does not include an explicit global source.
Not using an explicit global source may result in a different lockfile being generated depending on the gems you have installed locally before bundler is run.
Instead, define a global source in your Gemfile like this: source "https://rubygems.org".
Could not find gem 'mysql2' in locally installed gems.
root@ip-172-566-459-13-app:/#
`/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/activerecord-7.2.2.1/lib/active_record/connection_adapters/postgresql_adapter.rb:63:in “rescue in new_client”: База данных не найдена: discourse.
Доступные конфигурации баз данных можно найти в config/database.yml. (ActiveRecord::NoDatabaseError)
Чтобы исправить эту ошибку:
Не создали ли вы базу данных или не удалили ли её? Чтобы создать базу данных, выполните: bin/rails db:create
Не изменилось ли имя базы данных? Убедитесь, что в config/database.yml указано правильное имя базы данных.`
Решено: я запускал от имени пользователя root, пришлось переключиться на пользователя ‘discourse’. Импорт начался.
Итак, я купил вполне приличный сервер с 4 ядрами CPU и 16 ГБ ОЗУ. При текущей скорости миграции постов на их перенос у меня уйдет 9 дней. Пользователи были перенесены за 2,5 часа. Можно с уверенностью сказать, что в текущем виде это для меня не сработает, но хотя бы у меня будет несколько месяцев, чтобы разобраться в системе, пока я не найду решение для массовой миграции.
PS:
В скрипте миграции я заметил, что дубликаты адресов электронной почты не импортируются. По каким критериям определяется дубликат? Я обратил внимание, что xyz@gmail.com считается тем же самым, что и xyz+1@gmail.com и xy.z@gmail.com.
Я пробовал выполнять миграции на VPS с характеристиками, похожими на мой личный компьютер, но по какой-то причине это всегда было намного, намного медленнее, чем использование моего компьютера.
В наше время я всегда делаю миграции локально. Сколько у вас постов?
По сути, всё именно так. Проверка на уникальность выполняется для приведённого к нижнему регистру и нормализованного варианта указанного адреса электронной почты.
Мы нормализуем адрес, удаляя все точки и игнорируя всё, что идёт после + в имени пользователя.
Важным фактором является скорость одного процессора.
На моих машинах скорость 800–1000 пользователей или сообщений в минуту является довольно типичной.
Обратите внимание, что при окончательном импорте будут импортированы только те пользователи и сообщения, которые еще не были импортированы, поэтому это займет немного времени.
Отключите настройку сайта Normalize emails (по умолчанию она была отключена до недавнего времени). Вероятно, её следует отключить в этой функции здесь:
Вы можете добавить это в свою модифицированную версию скрипта для XenForo, используя SiteSetting.normalize_emails=false. Не уверен, что случилось с пользователями, у которых были дубликаты адресов электронной почты; есть два очевидных варианта: присвоить им поддельный адрес электронной почты или пропустить их импорт. Похоже, что им присваивают поддельные адреса? (И есть довольно высокая вероятность, что эти пользователи на самом деле являются фейковыми). Если же они были пропущены, то повторный запуск скрипта импортирует их.
Да, на моем ноутбуке всё работает гораздо быстрее — около 1000 элементов в минуту. Это примерно в два раза быстрее, чем на сервере. Тем не менее, это всё ещё около трёх дней.
Я просмотрел пропущенные письма, и, похоже, система хорошо справляется с игнорированием этих аккаунтов. Я просто объединю их перед финальным импортом. Таких случаев всего около 20.
Обратите внимание: при финальном импорте будут импортированы только те пользователи и посты, которые ещё не были импортированы, поэтому это займёт совсем немного времени.
Спасибо, что обратили на это внимание. Я сам это заметил, и, похоже, именно это и станет решающим фактором при финальном импорте. Значит, я делаю резервную копию и восстанавливаю её за 3 дня до D-0, а затем снова делаю резервную копию и восстанавливаю её с новым файлом базы данных в день D-0. Правильно ли я понял?
Эти резервные копии и восстановления делаются на сайте XenForo, или у вас есть действующий сайт Discourse, в который вы планируете импортировать данные из XenForo?
Пока вы не вносите изменения в скрипт, требующие повторного импорта данных, и то, что сейчас находится на вашем ноутбуке, является тем, что вы хотите видеть на сервере Discourse, вы можете просто продолжать делать новые дампы базы данных XenForo и импортировать их (для проверки, оценки времени выполнения и т. д.). А в день перехода вы заморозите сайт XenForo, сделаете дамп базы данных, ещё раз запустите скрипт и загрузите данные на свой сервер Discourse.
Если на вашем сайте Discourse уже есть данные, которые вы хотите сохранить, всё становится гораздо сложнее, так как вам придётся заморозить этот сайт, затем получить данные из XenForo и далее действовать, как описано выше.
Это будет чистая установка Discourse, что упрощает задачу.
У меня есть достаточно времени, так как я хочу несколько раз протестировать миграции, thoroughly изучить Discourse, настроить все дополнения так, как мне нужно, и, возможно, даже заняться кастомизацией некоторых из них.
То, что вы объяснили, полностью снимает одну из моих главных проблем, так как я думал, что мне придётся разбираться ещё и с пакетным импортом.
Вернулся с вопросом: выводит ли скрипт импорта какие-либо логи? Мой тестовый импорт завис на отметке 98,2% уже несколько часов.
Ещё один момент, который я заметил: если перезапустить миграцию, то пропуск партии из 1000 постов занимает около 30 секунд. Таким образом, фактическая скорость теперь составляет 2000 элементов в минуту. Это незначительное улучшение по сравнению со скоростью первого импорта (1000 постов в минуту), так как даже при последнем импорте в день переключения это займёт примерно сутки. 23 часа из которых будут потрачены просто на пропуск уже импортированных элементов.
Вам, вероятно, стоит остановить его и запустить заново.
Да, он пропустит все данные, которые уже были импортированы. При этом он делает это намного быстрее, чем 2000 сообщений в минуту. Я полагаю, вы это заметите, когда перезапустите его сейчас.
Удалось импортировать аватары и вложения. Скопировал следующие папки:
/internal_data/attachments
/data/avatars
Чтобы ответить на свой вопрос: аватары и вложения окончательно импортируются сразу после завершения процесса. Если пользователь изменит свой аватар после того, как его ID был импортирован, это изменение не будет импортировано или обновлено, так как этот пост или пользователь будут пропущены при втором запуске.
Теперь осталось разобраться с импортом сообщений (это можно пропустить, но было бы полезно) и постоянными перенаправлениями.
@Fajfi — спасибо за ваш вклад в скрипт импорта. Он безупречно сработал для аватаров и вложений. Процесс всё ещё выполняется, и пока не дошёл до этапа импорта лайков.
Исправил импорт сообщений. Удалось импортировать более полумиллиона сообщений из XF2.3 в Discourse. Создал PR, если кому-то это интересно.
----РЕДАКТИРОВАНИЕ----
Создал ещё один PR с исправлением для импорта лайков. Удивительно, что никто до сих пор не мигрировал с XF2.1+ на Discourse. Лайки были переименованы в реакции в 2019 году при выпуске XF2.1.