¡Gracias por la información tan valiosa!

Tengo otra pregunta sobre la consulta SQL que selecciona los usuarios de vBulletin.

Cuando importé mi antiguo foro phpBB a Discourse hace 3 años, había unos 20.000 usuarios. Obviamente, la mayoría eran cuentas inactivas. Durante estos 3 años, Discourse ha realizado su propia limpieza de usuarios inactivos, y ahora tenemos un número más realista de 3.000 miembros.

Cuando importé mis 180.000 usuarios de vBulletin y pedí a Discourse que realizara su tarea de limpieza de forma agresiva, me quedé con 27.000 usuarios, lo cual parece razonable.

En mi vBulletin, dado que:

1. Todos los mensajes publicados por usuarios en los perfiles de otros usuarios se importan a Discourse como temas sin categoría y sin título, que no aportan nada más que ruido innecesario, y
2. La gran mayoría de los usuarios que publicaron solo en los perfiles de otros usuarios parecen ser spammers,
   me gustaría realizar la limpieza durante la importación y no después.

No entiendo toda la base de datos de vBulletin, que es un poco confusa con su sistema de nodos, pero me gustaría importar solo los usuarios que han publicado al menos 1 tópico o respuesta.
Me parece que los tópicos y las respuestas rellenan el campo lastpostid en la tabla de usuarios de vBulletin, pero las publicaciones públicas del perfil no lo hacen.

Sí, tengo la intención de editar:

  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}

a:

  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}

Solo he añadido un WHERE u.lastpost > 0.

Un conteo con esta consulta me da 25.000 usuarios, en comparación con los 27.000 usuarios activos de mi importación anterior, después de la limpieza de Discourse pero aún con esos temas sin título (antiguos mensajes públicos del perfil). Eso significaría que unos 2.000 usuarios habrían publicado solo en los perfiles de otros usuarios, lo cual no es un número absurdo.

¿Crees que mi razonamiento es correcto y que añadir WHERE u.lastpost > 0 limpiará adecuadamente mi base de usuarios sin tener ningún efecto perjudicial?

Depende de dónde se haya alojado tu base de datos. Si fue migrada desde phpBB a vBulletin o si ha pasado por muchas actualizaciones de vBulletin, este razonamiento podría ser incorrecto.

Lo mejor que puedes hacer es verificar tu razonamiento ejecutando más consultas, por ejemplo, listando todas las publicaciones realizadas por los usuarios sin un lastpost.

Además, si tienes plugins como “me gusta” o “votación”, podrías estar eliminando usuarios que no deberías eliminar.

Mi estrategia es ser muy conservador al eliminar o dejar de lado elementos. El almacenamiento es económico.

Gracias, haré lo que dices; prefiero ir con cuidado.
Dejaré que Discourse haga su propia limpieza con el tiempo.

Llevo días añadiendo expresiones regulares personalizadas para limpiar publicaciones en tu script de migración, ya que el foro es muy antiguo y fue migrado desde phpBB antes que vBulletin, por lo que hubo que atender muchos detalles. Creo, y espero, que estoy cerca de finalizar todo.

No conozco muy bien vBulletin, pero el foro en el que estoy trabajando usaba vBulletin 5.6, y algunas imágenes externas que publiqué allí utilizaban esta sintaxis en la base de datos de vBulletin:
[IMG2=JSON]{"data-align":"none","data-size":"full","src":"https:\/\/forum.monocycle.info\/uploads\/default\/original\/2X\/3\/396192845ba93e7df2a6109a2608072efa21ee32.jpeg"}[/IMG2]
No estoy seguro de si esto fue “olvidado” en tu script o si el administrador del foro usó algún plugin que generaba estas etiquetas img2.

En cualquier caso, las arreglé con este código:

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

Tengo una pregunta: ¿Discourse volverá a generar automáticamente las publicaciones importadas con el tiempo? Si es así, ¿empezará por las publicaciones más recientes?

Hola de nuevo,

Mi foro tiene unas 1000 etiquetas, pero probablemente no las usaremos en Discourse. Además, estas etiquetas probablemente estén bastante desordenadas. ¿Puedo simplemente comentar esta línea en el importador:

    import_tags

¿O podría haber algún efecto secundario?

Puedes comentarlo de forma segura.

¿Es seguro no esperar a que Sidekiq termine sus trabajos después de importar algo?

He importado mis usuarios y este es el estado actual de Sidekiq.

image1182×324 27.3 KB

¿Qué sucede con estas tareas si creo una copia de seguridad y la restauro en un foro de producción?

No, aunque un rebake completo volverá a crear la mayoría de estos trabajos, te recomendaría absolutamente que esperes.

Seguirán ejecutándose… en la instancia de importación.
No se incluirán en la copia de seguridad ni se transferirán al foro de producción.

¡Gracias!

Debido a algunos mensajes de error durante la restauración de copias de seguridad (que no impiden que finalice la restauración ni que el foro funcione), me preguntaba si podría ser porque no esperé a que Sidekiq terminara su trabajo.

Inicié una nueva importación desde vBulletin: solo importé grupos y 30,000 usuarios en mi Discourse de desarrollo, esperé varias decenas de minutos, luego creé una copia de seguridad y la restauré en una instalación basada en Docker. La restauración funcionó, pero los registros muestran estos errores:

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 ((...

Son inconsistentes y los errores de relación varían de una copia de seguridad a otra. No logro entender de dónde provienen.

TL;DR: No creo que esos errores estén relacionados con la importación de ninguna manera.

He visto eso antes; creo que se trata de una condición de carrera que ocurre porque la base de datos se está accediendo mientras se restaura la copia de seguridad.

Esto podría deberse al tráfico regular que llega a tu servidor o a un proceso de Sidekiq que no se ha pausado. En ambos casos, es inofensivo. Si yo fuera tú, ignoraría por completo todos los errores de PG que ocurran antes de que la restauración se haya completado totalmente.

¡Eso es tranquilizador!

El caso es que no solo los mensajes en sí mismos me dan un poco de miedo, sino que también son preocupantes porque:

1. ocurren en cada (o casi cada? ) copia de seguridad que he creado desde que comencé mi importación, ya sea que restaure la copia en un foro local de desarrollo o en una instalación en línea con Docker.
2. impiden que el registro de restauración (en la interfaz de copias de seguridad de Discourse) siga escribiéndose en la interfaz de Discourse mientras se realiza la restauración: se queda pegado en “descomprimiendo el archivo” (o “Creando funciones faltantes en el esquema discourse_functions…” si se trata de una copia de seguridad sin archivos adjuntos).
   Parece que algo ha fallado, pero si espero, después de un tiempo siempre se cierra mi sesión automáticamente y, al volver a iniciar sesión, la importación parece haber funcionado correctamente a pesar de estos mensajes de error.

Dado que el foro funciona (a excepción de la edición de categorías que provoca un error 502 que describí en otro hilo), solo temo que el foro funcione… hasta que deje de hacerlo por alguna razón dentro de unas semanas/meses/años debido a algo que no logré detectar antes, lo cual realmente no quiero que suceda, especialmente porque he estado trabajando en esta importación todos los días durante un mes y contando.

De todos modos, gracias por tu ayuda, es muy apreciada. Estoy dedicando mucha energía a este trabajo de importación no remunerado para una comunidad grande, y tener personas que respondan a mis preguntas siempre es un alivio.

Primero, gracias por publicar esto. Acabo de probar la importación de vBulletin 3.7.x. Seguí todos los pasos, pero al ejecutar el script de importación dice que no puede conectarse, aunque yo sí puedo. ¿Alguna idea?

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
Cargando grupos existentes...
Cargando usuarios existentes...
Cargando categorías existentes...
Cargando publicaciones existentes...
Cargando temas existentes...
==================================================
Acceso denegado para el usuario 'root'@'localhost'
No se puede conectar a la base de datos.

Nombre de host: localhost
Nombre de usuario: root
Contraseña: 1234
Base de datos: vb4

Edita el script o establece estas variables de entorno:

export DB_HOST="localhost"
export DB_NAME="vbulletin"
export DB_PW=""
export DB_USER="root"
export TABLE_PREFIX="vb_"
export ATTACHMENT_DIR '/ruta/a/tu/carpeta_de_adjuntos'

Saliendo.

A continuación puedes ver que puedo iniciar sesión en la base de datos usando las mismas credenciales y he validado el nombre de la base de datos y el prefijo de tabla.

root@uat-app:/var/www/discourse# mysql -uroot -p1234 -hlocalhost
Bienvenido al monitor de MariaDB. Los comandos terminan con ; o \g.
El ID de conexión de MariaDB es 70
Versión del servidor: 10.3.25-MariaDB-0+deb10u1 Debian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab y otros.

Escribe 'help;' o '\h' para obtener ayuda. Escribe '\c' para borrar la instrucción de entrada actual.

MariaDB [(none)]> use vb4;
Leyendo información de tabla para completar los nombres de tablas y columnas
Puedes desactivar esta función para obtener un inicio más rápido con -A

Base de datos cambiada
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 fila en el conjunto (0.001 seg)

MariaDB [vb4]>

Además, he exportado los avatares desde /admincp/avatar.php?do=storage y los he guardado en tres carpetas diferentes de la siguiente manera:

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

¿Debo especificar entonces la carpeta principal así? ¿O tengo que tomar el contenido de las tres carpetas y ponerlas en una sola?

export ATTACHMENT_DIR='/shared/vbulletin'

Mi única suposición es que tal vez tu contraseña tenga caracteres especiales.

En realidad, no son más que caracteres alfanuméricos. De todos modos, lo he probado de nuevo y confirmado que no funciona hasta que establezco explícitamente la contraseña. También he notado que las instrucciones necesitan actualizarse, así que copio aquí lo que funciona para mí.

Las instrucciones necesitan actualizarse. Aquí está lo que funciona para mí a partir de noviembre de 2020. Tenga en cuenta que es mejor ejecutar esta importación usando screen, ya que la importación puede tardar horas, y usar nohup probablemente no sea útil porque el script de importación actualizará constantemente el número de cada elemento importado, por lo que el archivo de salida estándar (stdout) probablemente será grande.

Instalar la Base de Datos para Alojar Datos de vBulletin

Descargar los Paquetes Más Recientes

Tenga en cuenta que MySQL ya no está disponible a menos que el repositorio de Oracle MySQL se agregue explícitamente a la lista de repositorios. MariaDB ha reemplazado a MySQL.

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

Iniciar la Base de Datos

root@uat-app:~# service mysql status
[info] MariaDB está detenida..
root@uat-app:~#
root@uat-app:~# service mysql start
[ ok ] Iniciando servidor de base de datos MariaDB: mysqld.
root@uat-app:~# service mysql status
[info] /usr/bin/mysqladmin Versión 9.1 Distribución 10.3.25-MariaDB, para debian-linux-gnu en x86_64
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab y otros.

Versión del servidor 10.3.25-MariaDB-0+deb10u1
Versión del protocolo 10
Conexión Localhost a través de socket UNIX
Socket UNIX /var/run/mysqld/mysqld.sock
Tiempo activo: 4 seg

Hilos: 7 Preguntas: 461 Consultas lentas: 0 Aperturas: 177 Limpiar tablas: 1 Tablas abiertas: 31 Consultas por segundo promedio: 115.250.

Instalar Gems para la Conectividad de la Base de Datos

A continuación se muestra que el último ‘bundle’ no le gustan algunos de los标志 en las instrucciones originales y es necesario desactivar el modo ‘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] La bandera `--path` está obsoleta porque depende de ser recordada entre las invocaciones de bundler, lo cual bundler ya no hará en versiones futuras. En su lugar, por favor use `bundle config set path 'vendor/bundle'`, y deje de usar esta bandera
[DEPRECATED] La bandera `--without` está obsoleta porque depende de ser recordada entre las invocaciones de bundler, lo cual bundler ya no hará en versiones futuras. En su lugar, por favor use `bundle config set without 'development'`, y deje de usar esta bandera
Está intentando instalar en modo de implementación después de cambiar
su Gemfile. Ejecute `bundle install` en otro lugar y agregue el
Gemfile.lock actualizado al control de versiones.

Si esta es una máquina de desarrollo, elimine la congelación de /var/www/discourse/Gemfile ejecutando `bundle config unset deployment`.

Las dependencias en su gemfile han cambiado

Ha agregado al Gemfile:
* mysql2
* php_serialize

Actualizar la Configuración y Volver a Ejecutar la Instalación

Verificar por CLI

La verificación de la configuración confirmó que está establecida en modo ‘deployment’.

root@uat-app:/var/www/discourse# bundle config list
Los ajustes se listan en orden de prioridad. El valor superior se utilizará.
deployment
Establecido para su aplicación local (/var/www/discourse/.bundle/config): true

jobs
Establecido para su aplicación local (/var/www/discourse/.bundle/config): 4

retry
Establecido para su aplicación local (/var/www/discourse/.bundle/config): 3

path
Establecido para su aplicación local (/var/www/discourse/.bundle/config): "vendor/bundle"

without
Establecido para su aplicación local (/var/www/discourse/.bundle/config): [:development, :test]

Verificar Inspeccionando el Archivo de Configuración

A continuación se realiza la misma verificación inspeccionando el archivo de configuración.

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"

Actualizar la Configuración

root@uat-app:/var/www/discourse# bundle config set path 'vendor/bundle'
Su aplicación ha establecido path a "vendor/bundle". Esto anulará el valor global que está configurando actualmente
root@uat-app:/var/www/discourse# bundle config set without 'development:test'
Su aplicación ha establecido without a "development:test". Esto anulará el valor global que está configurando actualmente
root@uat-app:/var/www/discourse# bundle config unset deployment

Validar la Configuración de Nuevo

root@uat-app:/var/www/discourse# bundle config list
Los ajustes se listan en orden de prioridad. El valor superior se utilizará.
path
Establecido para su aplicación local (/var/www/discourse/.bundle/config): "vendor/bundle"
Establecido para el usuario actual (/root/.bundle/config): "vendor/bundle"

without
Establecido para su aplicación local (/var/www/discourse/.bundle/config): [:development, :test]
Establecido para el usuario actual (/root/.bundle/config): [:development, :test]

jobs
Establecido para su aplicación local (/var/www/discourse/.bundle/config): 4

retry
Establecido para su aplicación local (/var/www/discourse/.bundle/config): 3

Intentar la Instalación de Nuevo

Ejecute la instalación nuevamente para los Gems y salga del contenedor.

root@uat-app:/var/www/discourse# su discourse -c 'bundle install'
...........
¡Bundle completo! 125 dependencias de Gemfile, 163 gems ahora instaladas.
Las gems en los grupos development y test no fueron instaladas.
Las gems agrupadas están instaladas en `./vendor/bundle`
root@uat-app:/var/www/discourse# exit

Crear Directorio para Datos de vBulletin

Crear Directorio

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

Copiar la Base de Datos de vBulletin

[root@uat standalone]# scp <usuario de inicio de sesión>@<IP del servidor vbulletin>:/home/backup/vbulletin/vbulletin-2020-11-14-03:30:01.sql.bz2 ./vbulletin/.

Descomprimir la Base de Datos de 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

Configurar la Fuente de Datos

Crear la Base de Datos vb4

root@uat-app:/shared/vbulletin# mysql -uroot -p -e 'CREATE DATABASE vb4'
Introduzca la contraseña:

Importar vBulletin a MariaDB

root@uat-app:/shared/vbulletin# mysql -uroot -p vb4 < vbulletin-2020-11-14-03\:30\:01.sql
Introduzca la contraseña:

Descomprimir los Archivos de Perfiles

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

Actualizar la Contraseña Raíz de la Base de Datos

root@uat-app:/var/www/discourse# mysql -uroot -p
Introduzca la contraseña:
Bienvenido al monitor MariaDB. Los comandos terminan con ; o \g.
Su ID de conexión de MariaDB es 77
Versión del servidor: 10.3.25-MariaDB-0+deb10u1 Debian 10

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab y otros.

Escriba 'help;' o '\h' para obtener ayuda. Escriba '\c' para borrar la declaración de entrada actual.

MariaDB [(none)]> ALTER USER 'root'@'localhost' IDENTIFIED BY '1234';
Consulta OK, 0 filas afectados (0.001 seg)

MariaDB [(none)]> quit
Adiós

Importar a Discourse

Establecer los Detalles de Conexión de la Fuente de Datos

[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 quiere vb4
Cargando grupos existentes...
Cargando usuarios existentes...
Cargando categorías existentes...
Cargando publicaciones existentes...
Cargando temas existentes...

importando grupos...
15 / 15 (100.0%) [3272 elementos/min] n]
importando usuarios
117 / 11033 ( 1.1%) [145 elementos/min] in]

¿Entonces el problema con tu conexión inicial a la base de datos era la mezcla de bibliotecas?

No creo que sea eso. Literalmente acabo de cambiar la contraseña explícitamente y pudo ejecutarse. Ahora tengo un problema al importar mensajes privados. Estoy viendo muchas de las siguientes líneas. ¿Tienes alguna idea de qué se trata?

importando mensajes privados...
      139 / 177409 (  0.1%)  [399 elementos/min]  uno de los IDs de los participantes es nil -- [nil, 270]
pm-149 no tiene destinatario (a:1:{i:486;s:5:"TonyN";})
      364 / 177409 (  0.2%)  [418 elementos/min]  uno de los IDs de los participantes es nil -- [nil, 276]
pm-420 no tiene destinatario (a:1:{i:623;s:14:"the other side";})
      571 / 177409 (  0.3%)  [414 elementos/min]  uno de los IDs de los participantes es nil -- [nil, 445]
pm-702 no tiene destinatario (a:1:{i:767;s:6:"greatg";})
      572 / 177409 (  0.3%)  [414 elementos/min]  uno de los IDs de los participantes es nil -- [nil, 445]
      605 / 177409 (  0.3%)  [416 elementos/min]  uno de los IDs de los participantes es nil -- [nil, 461]

O bien es que esos usuarios no se importaron por alguna razón (la falta de una dirección de correo electrónico solía ser una causa, pero eso ya debería estar resuelto), o bien, por alguna otra razón, el código que busca los nombres de usuario importados no funciona (quizás el problema sea la mayúscula o minúscula del nombre de usuario).

@pfaffman sí, parece así, aunque no está claro en algunos de los detalles específicos. Veamos el primero, por ejemplo.

1. ¿Qué significa pm-149?
2. En a:1:{i:486;s:5:"TonyN";}, el texto “TonyN” parece ser el nombre de usuario, pero ¿qué significan los demás números?
3. ¿Y qué hay de [nil, 270]? ¿Qué indica 270?

Si puedo entender de qué se queja, al menos podré intentar consultar la base de datos para ver si hay algún problema con los datos. Pero no estoy seguro de qué significan realmente estos valores.

Por cierto, también noté que todos los foros importados tienen permisos para todos. Esto significa que los foros que solo estaban permitidos para moderadores se configuraron como visibles para todos. ¿Hay alguna forma de controlar esto?

Lo siento. No lo recuerdo lo suficientemente bien como para explicarlo. Esto es todo el apoyo gratuito que puedo ofrecer sobre este tema.

Por supuesto. Consulta Understanding groups and category permissions

Algunos importadores se esfuerzan por importar grupos, pero pocos saben cómo aplicar esos permisos a las categorías que se importan. Tendrás que arreglarlos manualmente.

Siguiendo las instrucciones de @titusc, parece que tengo problemas al importar la base de datos…

root@DO-Discourse-app:/shared/vbulletin# mysql -uroot -p vb4 < CC12-Sat-Full-Backup.sql
Introduzca la contraseña:
ERROR 1265 (01000) en la línea 4928: Datos truncados para la columna 'method' en la fila 1
root@DO-Discourse-app:/shared/vbulletin#

¿Alguna sugerencia sobre lo que está buscando?

N/M Son errores en la base de datos original…