Спасибо за ценную информацию!

У меня ещё один вопрос, касающийся SQL-запроса для выборки пользователей vBulletin.

Когда я импортировал свой старый форум phpBB в Discourse три года назад, там было около 20 000 пользователей. Очевидно, что большинство из них были неактивными аккаунтами. За эти три года Discourse провёл собственную очистку неактивных пользователей, и теперь у нас более реалистичное число — 3000 участников.

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

На моём vBulletin:

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

Я не до конца понимаю структуру базы данных vBulletin, которая немного запутана из-за системы узлов, но я хотел бы импортировать только тех пользователей, которые создали хотя бы 1 тему или ответ.
Мне кажется, что темы и ответы заполняют поле lastpostid в таблице пользователей vBulletin, а публичные сообщения на профилях — нет.

Да, я планирую изменить

  SELECT u.userid, u.username, u.homepage, u.usertitle, u.usergroupid, u.joindate, u.email
    CASE WHEN u.scheme='blowfish:10' THEN token
         WHEN u.scheme='legacy' THEN REPLACE(token, ' ', ':')
    END AS password,
    IF(ug.title = 'Administrators', 1, 0) AS admin
    FROM #{DB_PREFIX}user u
    LEFT JOIN #{DB_PREFIX}usergroup ug ON ug.usergroupid = u.usergroupid
ORDER BY userid
   LIMIT #{BATCH_SIZE}
  OFFSET #{offset}

на:

  SELECT u.userid, u.username, u.homepage, u.usertitle, u.usergroupid, u.joindate, u.email, u.lastpost
    CASE WHEN u.scheme='blowfish:10' THEN token
         WHEN u.scheme='legacy' THEN REPLACE(token, ' ', ':')
    END AS password,
    IF(ug.title = 'Administrators', 1, 0) AS admin
    FROM #{DB_PREFIX}user u
    LEFT JOIN #{DB_PREFIX}usergroup ug ON ug.usergroupid = u.usergroupid
    WHERE u.lastpost > 0
ORDER BY userid
   LIMIT #{BATCH_SIZE}
  OFFSET #{offset}

Я просто добавляю WHERE u.lastpost > 0.

Подсчёт с этим запросом даёт мне 25 000 пользователей, по сравнению с 27 000 активных пользователей после предыдущего импорта, когда уже была проведена очистка в Discourse, но всё ещё присутствовали эти темы без заголовков (бывшие публичные сообщения на профилях). Это означало бы, что около 2000 пользователей писали только на чужих профилях, что не является абсурдным числом.

Как вы думаете, мои рассуждения верны, и добавление WHERE u.lastpost > 0 позволит аккуратно очистить базу пользователей без каких-либо вредных последствий?

Это зависит от того, где находилась ваша база данных. Если она была перенесена с phpBB на vBulletin или прошла через множество обновлений vBulletin, то такое рассуждение может быть неверным.

Лучшее, что вы можете сделать, — проверить свои предположения, выполнив дополнительные запросы, например, перечислив все сообщения пользователей без lastpost.

Также, если у вас есть плагины, такие как «лайки» или «голосование», вы можете удалить пользователей, которых не следует удалять.

Моя стратегия — быть очень осторожным при удалении или исключении чего-либо. Хранилище стоит недорого.

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

Я уже несколько дней добавляю регулярные выражения для очистки пользовательских постов в ваш скрипт миграции, потому что форум очень старый и был перенесён с phpBB до vBulletin, поэтому пришлось учесть множество деталей. Но я думаю и надеюсь, что почти завершил всё.

Я не очень хорошо знаю vBulletin, но форум, над которым я работаю, использовал vBulletin 5.6, и некоторые внешние изображения, которые я там публиковал, в базе данных vBulletin хранились в таком синтаксисе:
[IMG2=JSON]{"data-align":"none","data-size":"full","src":"https:\/\/forum.monocycle.info\/uploads\/default\/original\/2X\/3\/396192845ba93e7df2a6109a2608072efa21ee32.jpeg"}[/IMG2]
Не уверен, было ли это «забыто» в вашем скрипте или же администратор форума использовал какой-то плагин, генерирующий такие теги img2.

В любом случае, я исправил это с помощью этого кода:

    raw = raw.gsub(/\[img2=json\].+?(http.+?).}\[\/img2\]/i) {"\n#{$1}\n"}

Однако у меня есть вопрос: будет ли Discourse автоматически переобрабатывать импортированные посты со временем? Если да, начнёт ли он с самых свежих постов?

Снова здравствуйте,

На моём форуме около 1000 тегов, но, скорее всего, мы не будем использовать их в Discourse. К тому же эти теги, вероятно, в полном беспорядке. Могу ли я просто закомментировать эту строку в импортере:

    import_tags

Или это может повлечь за собой побочные эффекты?

Вы можете безопасно закомментировать это.

Безопасно ли не дожидаться завершения задач sidekiq после импорта чего-либо?

Я импортировал пользователей, и вот текущее состояние sidekiq.

image1182×324 27.3 KB

Что произойдет с этими задачами, если я создам резервную копию и восстановлю её на производственном форуме?

Нет, хотя полная пересборка (rebuild) воссоздаст большинство этих задач, я настоятельно рекомендую вам подождать.

Они продолжат выполняться… на экземпляре импорта.
Они не будут включены в резервную копию и не будут перенесены на продакшн-форум.

Спасибо!

Из-за некоторых сообщений об ошибках во время восстановления резервных копий (которые не препятствуют завершению восстановления или работе форума), я задумался, не связано ли это с тем, что я не дождался завершения работы Sidekiq.

Я запустил новый импорт из vBulletin: импортировал только группы и 30 000 пользователей на моём dev-окружении Discourse, подождал несколько десятков минут, затем создал резервную копию и восстановил её на установке на базе Docker. Восстановление прошло успешно, но в логах появились следующие ошибки:

ActiveRecord::StatementInvalid (PG::UndefinedTable: ERROR: relation "users" does not exist LINE 1: SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1 ^ ) lib/a
10:03 pm
7
ActiveRecord::StatementInvalid (PG::UndefinedTable: ERROR: relation "user_auth_tokens" does not exist LINE 1: SELECT "user_auth_tokens".* FROM "user_auth_tokens" WHERE ((...

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

TL;DR: Я не думаю, что эти ошибки каким-либо образом связаны с импортом.

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

Это может быть вызвано обычным трафиком, поступающим на ваш сервер, или процессом Sidekiq, который не был приостановлен. В обоих случаях это безвредно. На вашем месте я бы полностью игнорировал все ошибки PG, возникающие до полного завершения восстановления.

Это обнадеживает!

Дело в том, что меня пугают не только сами сообщения об ошибках, но и то, что:

1. они возникают при каждой (или почти каждой? ) резервной копии, которую я создавал с момента начала импорта, независимо от того, восстанавливаю ли я её в локальном тестовом форуме или в онлайн-установке через Docker;
2. они мешают ведению журнала восстановления (в интерфейсе резервного копирования Discourse) — он перестаёт обновляться в интерфейсе Discourse во время процесса восстановления: зависает на этапе «распаковка архива» (или «Создание отсутствующих функций в схеме discourse_functions…», если резервная копия не содержит вложений).
   Кажется, что что-то аварийно завершило работу, но если подождать, то через некоторое время меня всегда корректно и автоматически выводит из системы. А когда я снова вхожу, импорт, судя по всему, завершился успешно, несмотря на эти сообщения об ошибках.

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

В любом случае, спасибо за помощь, я очень ценю её. Я вкладываю много сил в эту бесплатную работу по импорту для крупного сообщества, и то, что люди отвечают на мои вопросы, всегда приносит облегчение.

Спасибо за публикацию. Я только что попробовал импортировать vBulletin 3.7.x. Следовал всем инструкциям, но при запуске скрипта импорта появляется сообщение о том, что подключение невозможно, хотя я могу подключиться. Есть какие-нибудь идеи?

root@uat-app:/var/www/discourse# export DB_NAME="vb4"
root@uat-app:/var/www/discourse# export DB_USER="root"
root@uat-app:/var/www/discourse# export DB_PW="1234"
root@uat-app:/var/www/discourse# export TABLE_PREFIX="vbulletin"
root@uat-app:/var/www/discourse# export ATTACHMENT_DIR='/shared/vbulletin'
root@uat-app:/var/www/discourse# export TIMEZONE="America/Vancouver"
root@uat-app:/var/www/discourse# su discourse -c 'bundle exec ruby script/import_scripts/vbulletin.rb'
root:1234@localhost wants vb4
Загрузка существующих групп...
Загрузка существующих пользователей...
Загрузка существующих категорий...
Загрузка существующих сообщений...
Загрузка существующих тем...
==================================================
Отказано в доступе для пользователя 'root'@'localhost'
Невозможно подключиться к базе данных.

Имя хоста: localhost
Имя пользователя: root
Пароль: 1234
База данных: vb4

Отредактируйте скрипт или установите следующие переменные окружения:

export DB_HOST="localhost"
export DB_NAME="vbulletin"
export DB_PW=""
export DB_USER="root"
export TABLE_PREFIX="vb_"
export ATTACHMENT_DIR '/path/to/your/attachment/folder'

Выход.

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

root@uat-app:/var/www/discourse# mysql -uroot -p1234 -hlocalhost
Добро пожаловать в монитор MariaDB. Команды заканчиваются на ; или \g.
ID соединения MariaDB: 70
Версия сервера: 10.3.25-MariaDB-0+deb10u1 Debian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab и другие.

Введите 'help;' или '\h' для справки. Введите '\c', чтобы очистить текущую команду.

MariaDB [(none)]> use vb4;
Чтение информации о таблицах для завершения имен таблиц и столбцов
Вы можете отключить эту функцию для более быстрого запуска с флагом -A

База данных изменена
MariaDB [vb4]> select * from information_schema.tables where table_schema = 'vb4' and table_name = 'vbulletinpost'
    -> ;
+---------------+--------------+---------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-------------------+----------+----------------+---------------+--------------------+-----------+
| TABLE_CATALOG | TABLE_SCHEMA | TABLE_NAME    | TABLE_TYPE | ENGINE | VERSION | ROW_FORMAT | TABLE_ROWS | AVG_ROW_LENGTH | DATA_LENGTH | MAX_DATA_LENGTH | INDEX_LENGTH | DATA_FREE | AUTO_INCREMENT | CREATE_TIME         | UPDATE_TIME         | CHECK_TIME          | TABLE_COLLATION   | CHECKSUM | CREATE_OPTIONS | TABLE_COMMENT | MAX_INDEX_LENGTH   | TEMPORARY |
+---------------+--------------+---------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-------------------+----------+----------------+---------------+--------------------+-----------+
| def           | vb4          | vbulletinpost | BASE TABLE | MyISAM |      10 | Dynamic    |    1037509 |            356 |   370191960 | 281474976710655 |     53087232 |         0 |        1046506 | 2020-11-14 14:27:01 | 2020-11-14 14:27:28 | 2020-11-14 14:27:32 | latin1_swedish_ci |     NULL |                |               | 288230376151710720 | N         |
+---------------+--------------+---------------+------------+--------+---------+------------+------------+----------------+-------------+-----------------+--------------+-----------+----------------+---------------------+---------------------+---------------------+-------------------+----------+----------------+---------------+--------------------+-----------+
1 row in set (0.001 sec)

MariaDB [vb4]>

Кроме того, я экспортировал аватары через /admincp/avatar.php?do=storage и сохранил их в три разные папки следующим образом:

/shared/vbulletin/signaturepics/
/shared/vbulletin/customprofilepics/
/shared/vbulletin/customavatars/

Должен ли я указать родительскую папку так?
export ATTACHMENT_DIR='/shared/vbulletin'
Или мне нужно объединить содержимое этих трёх папок в одну?

Мое единственное предположение: возможно, в вашем пароле есть специальные символы?

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

Инструкции необходимо обновить. Вот что работает у меня по состоянию на ноябрь 2020 года. Обратите внимание, что действительно лучше запускать этот импорт через screen, так как импорт может занять несколько часов, а использование nohup, скорее всего, не поможет, поскольку скрипт импорта постоянно обновляет количество импортированных элементов каждого типа, и файл stdout, вероятно, будет очень большим.

Установка базы данных для переноса данных vBulletin

Загрузка последних пакетов

Обратите внимание: MySQL больше недоступен, если репозиторий Oracle MySQL явно не добавлен в список репозиториев. MySQL заменён на MariaDB.

root@uat-app:~# apt-get update
root@uat-app:~# apt-get install libmariadb-dev
root@uat-app:~# apt-get install default-mysql-server

Запуск базы данных

root@uat-app:~# service mysql status
[info] MariaDB остановлен..
root@uat-app:~#
root@uat-app:~# service mysql start
[ ok ] Запуск сервера базы данных MariaDB: mysqld.
root@uat-app:~# service mysql status
[info] /usr/bin/mysqladmin Версия 9.1, Дистрибутив 10.3.25-MariaDB, для debian-linux-gnu на x86_64
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab и другие.

Версия сервера 10.3.25-MariaDB-0+deb10u1
Версия протокола 10
Подключение: локально через UNIX-сокет
UNIX-сокет /var/run/mysqld/mysqld.sock
Время работы: 4 сек

Потоки: 7 Запросов: 461 Медленных запросов: 0 Открыто соединений: 177 Сброс таблиц: 1 Открыто таблиц: 31 Среднее кол-во запросов в секунду: 115.250.

Установка Gem-ов для подключения к базе данных

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

root@uat-app:~# echo "gem 'mysql2', require: false" >> /var/www/discourse/Gemfile

root@uat-app:~# echo "gem 'php_serialize', require: false" >> /var/www/discourse/Gemfile

root@uat-app:~# cd /var/www/discourse
root@uat-app:/var/www/discourse# su discourse -c 'bundle install --no-deployment --without test --without development --path vendor/bundle'
[DEPRECATED] Флаг `--path` устарел, так как он полагается на сохранение между вызовами bundler, чего bundler больше не будет делать в будущих версиях. Вместо этого используйте `bundle config set path 'vendor/bundle'` и прекратите использовать этот флаг.
[DEPRECATED] Флаг `--without` устарел, так как он полагается на сохранение между вызовами bundler, чего bundler больше не будет делать в будущих версиях. Вместо этого используйте `bundle config set without 'development'` и прекратите использовать этот флаг.
Вы пытаетесь установить в режиме развёртывания после изменения
вашего Gemfile. Запустите `bundle install` в другом месте и добавьте
обновлённый Gemfile.lock в систему контроля версий.

Если это машина разработки, отмените заморозку /var/www/discourse/Gemfile, выполнив `bundle config unset deployment`.

Зависимости в вашем gemfile изменились

Вы добавили в Gemfile:
* mysql2
* php_serialize

Обновление конфигурации и повторный запуск установки

Проверка через CLI

Проверка конфигурации подтвердила, что установлен режим deployment.

root@uat-app:/var/www/discourse# bundle config list
Настройки перечислены в порядке приоритета. Используется верхнее значение.
deployment
Установлено для вашего локального приложения (/var/www/discourse/.bundle/config): true

jobs
Установлено для вашего локального приложения (/var/www/discourse/.bundle/config): 4

retry
Установлено для вашего локального приложения (/var/www/discourse/.bundle/config): 3

path
Установлено для вашего локального приложения (/var/www/discourse/.bundle/config): "vendor/bundle"

without
Установлено для вашего локального приложения (/var/www/discourse/.bundle/config): [:development, :test]

Проверка путём просмотра файла конфигурации

Ниже показана та же проверка путём просмотра файла конфигурации.

root@uat-app:/var/www/discourse# cat /var/www/discourse/.bundle/config
---
BUNDLE_DEPLOYMENT: "true"
BUNDLE_JOBS: "4"
BUNDLE_RETRY: "3"
BUNDLE_PATH: "vendor/bundle"
BUNDLE_WITHOUT: "development:test"

Обновление конфигурации

root@uat-app:/var/www/discourse# bundle config set path 'vendor/bundle'
Ваше приложение установило path в "vendor/bundle". Это переопределит глобальное значение, которое вы в настоящее время устанавливаете.
root@uat-app:/var/www/discourse# bundle config set without 'development:test'
Ваше приложение установило without в "development:test". Это переопределит глобальное значение, которое вы в настоящее время устанавливаете.
root@uat-app:/var/www/discourse# bundle config unset deployment

Повторная проверка конфигурации

root@uat-app:/var/www/discourse# bundle config list
Настройки перечислены в порядке приоритета. Используется верхнее значение.
path
Установлено для вашего локального приложения (/var/www/discourse/.bundle/config): "vendor/bundle"
Установлено для текущего пользователя (/root/.bundle/config): "vendor/bundle"

without
Установлено для вашего локального приложения (/var/www/discourse/.bundle/config): [:development, :test]
Установлено для текущего пользователя (/root/.bundle/config): [:development, :test]

jobs
Установлено для вашего локального приложения (/var/www/discourse/.bundle/config): 4

retry
Установлено для вашего локального приложения (/var/www/discourse/.bundle/config): 3

Попытка повторной установки

Повторно запустите установку для Gem-ов и выйдите из контейнера.

root@uat-app:/var/www/discourse# su discourse -c 'bundle install'
...........
Установка завершена! 125 зависимостей Gemfile, 163 gem-а теперь установлены.
Gem-ы в группах development и test не были установлены.
Установленные gem-ы размещены в `./vendor/bundle`
root@uat-app:/var/www/discourse# exit

Создание каталога для данных vBulletin

Создание каталога

[root@uat standalone]# pwd
/var/discourse/shared/standalone
[root@uat standalone]# mkdir vbulletin

Копирование базы данных vBulletin

[root@uat standalone]# scp <пользователь_входа>@<IP_сервера_vbulletin>:/home/backup/vbulletin/vbulletin-2020-11-14-03:30:01.sql.bz2 ./vbulletin/.

Распаковка базы данных vBulletin

[root@uat containers]# docker exec -it app bash
root@uat-app:/# cd /shared/vbulletin
root@uat-app:/shared/vbulletin# bunzip2 vbulletin-2020-11-14-03\:30\:01.sql.bz2

Настройка источника данных

Создание базы данных vb4

root@uat-app:/shared/vbulletin# mysql -uroot -p -e 'CREATE DATABASE vb4'
Введите пароль:

Импорт vBulletin в MariaDB

root@uat-app:/shared/vbulletin# mysql -uroot -p vb4 < vbulletin-2020-11-14-03\:30\:01.sql
Введите пароль:

Распаковка архивов профилей

[root@uat vbulletin]# tar xvfz signaturepics.tar.gz
[root@uat vbulletin]# tar xvfz customavatars.tar.gz
[root@uat vbulletin]# tar xvfz customprofilepics.tar.gz

Обновление корневого пароля базы данных

root@uat-app:/var/www/discourse# mysql -uroot -p
Введите пароль:
Добро пожаловать в монитор MariaDB. Команды заканчиваются ; или \g.
Ваш идентификатор подключения MariaDB: 77
Версия сервера: 10.3.25-MariaDB-0+deb10u1 Debian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab и другие.

Введите 'help;' или '\h' для справки. Введите '\c' для очистки текущего ввода.

MariaDB [(none)]> ALTER USER 'root'@'localhost' IDENTIFIED BY '1234';
Запрос OK, 0 строк затронуто (0.001 сек)

MariaDB [(none)]> quit
Пока

Импорт в Discourse

Установка параметров подключения к источнику данных

[root@uat vbulletin]# export DB_NAME="vb4"
[root@uat vbulletin]# export DB_USER="root"
[root@uat vbulletin]# export DB_PW="1234"
[root@uat vbulletin]# export TABLE_PREFIX="vbulletin"
[root@uat vbulletin]# export ATTACHMENT_DIR='/shared/vbulletin'
[root@uat vbulletin]# export TIMEZONE="America/Vancouver"
[root@uat vbulletin]# cd /var/www/discourse
root@uat-app:/var/www/discourse# su discourse -c 'bundle exec ruby script/import_scripts/vbulletin.rb'
root:1234@localhost хочет vb4
Загрузка существующих групп...
Загрузка существующих пользователей...
Загрузка существующих категорий...
Загрузка существующих постов...
Загрузка существующих тем...

Импорт групп...
15 / 15 (100.0%) [3272 элементов/мин] n]
Импорт пользователей
117 / 11033 ( 1.1%) [145 элементов/мин] in]

Значит, проблема с вашим первоначальным подключением к базе данных заключалась в смешивании библиотек?

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

импортируются личные сообщения...
      139 / 177409 (  0.1%)  [399 элементов/мин]  один из идентификаторов участников равен nil -- [nil, 270]
pm-149 не имеет целевого получателя (a:1:{i:486;s:5:"TonyN";})
      364 / 177409 (  0.2%)  [418 элементов/мин]  один из идентификаторов участников равен nil -- [nil, 276]
pm-420 не имеет целевого получателя (a:1:{i:623;s:14:"the other side";})
      571 / 177409 (  0.3%)  [414 элементов/мин]  один из идентификаторов участников равен nil -- [nil, 445]
pm-702 не имеет целевого получателя (a:1:{i:767;s:6:"greatg";})
      572 / 177409 (  0.3%)  [414 элементов/мин]  один из идентификаторов участников равен nil -- [nil, 445]
      605 / 177409 (  0.3%)  [416 элементов/мин]  один из идентификаторов участников равен nil -- [nil, 461]

Либо эти пользователи не были импортированы по какой-то причине (отсутствие email-адреса было одной из причин, но это должно быть уже исправлено), либо по какой-то другой причине не работает код, который ищет импортированные имена пользователей (возможно, из-за регистра имени пользователя?).

@pfaffman да, выглядит именно так, хотя некоторые детали остаются неясными. Давайте, например, разберём первый случай.

1. Что означает pm-149?
2. В строке a:1:{i:486;s:5:"TonyN";} текст “TonyN” похож на имя пользователя, но что означают остальные числа?
3. А как насчёт [nil, 270]? Что означает число 270?

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

Кстати, я также заметил, что у всех импортированных форумов права доступа установлены для всех пользователей. Это означает, что форумы, которые должны были быть доступны только модераторам, стали видимыми для всех. Есть ли способ контролировать это?

Извините. Я не помню достаточно хорошо, чтобы объяснить. Это всё, что я могу предложить в качестве бесплатной помощи по этому вопросу.

Конечно. См. Understanding groups and category permissions

Некоторые импортеры пытаются импортировать группы, но лишь немногие из них знают, как применить эти разрешения к импортируемым категориям. Вам придётся исправить это вручную.

Следуя инструкциям @titusc, у меня возникли проблемы с импортом базы данных…

root@DO-Discourse-app:/shared/vbulletin# mysql -uroot -p vb4 < CC12-Sat-Full-Backup.sql
Введите пароль: 
ERROR 1265 (01000) at line 4928: Data truncated for column 'method' at row 1
root@DO-Discourse-app:/shared/vbulletin#

Есть какие-нибудь предложения, что именно требуется?

Не важно, это ошибки в исходной базе данных…