Multisite restaura las cargas a 'default' en lugar del nombre real de la base de datos

Desarrollador
1

En la última beta de Discourse, instalación con Docker y multisitio.

Estoy intentando restaurar una copia de seguridad con la base de datos original REDACTED a la base de datos actual db8015. Las cargas terminan en default, tanto en el sistema de archivos como en la base de datos.

Esto ocurre tanto cuando la restauración se activa desde la interfaz gráfica como cuando se realiza desde la línea de comandos usando RAILS_DB=db8015 RAILS_ENV=production script/discourse restore.

Durante el proceso de restauración, RailsMultisite::ConnectionManagement.current_db cambia de la base de datos correcta a default. He logrado rastrear esto hasta [Rake::Task['db:_dump'].invoke en db.rake](https://github.com/discourse/discourse/blame/master/lib/tasks/db.rake#L59).

Antes de esa línea, RailsMultisite::ConnectionManagement.current_db tiene el valor correcto (db8015); después de esa línea, es default.

Parece que esta corrección ha roto algo en producción, @sam.

Registros:

[INICIADO]
¡'DHSupport' ha comenzado la restauración!
Marcando la restauración como en curso...
Asegurando que existe /var/www/discourse/tmp/restores/db8015/2019-10-11-104940...
Copiando el archivo comprimido al directorio tmp...
Descomprimiendo el archivo comprimido, esto puede tardar un rato...
No hay archivo de metadatos para extraer.
Validando metadatos...
  Versión actual: 20191007140446
  Versión restaurada: 20190908234054
Extrayendo el archivo volcado...
Creando funciones faltantes en el esquema discourse_functions
No se puede restaurar en un esquema diferente, restaurando in-place
Habilitando el modo solo lectura...
Pausando sidekiq...

[se eliminó mucho contenido irrelevante]

Limpiando la caché de temas
Extrayendo cargas...
Reasignando cargas...
Reasignando 'uploads/REDACTED' a 'uploads/default'
Optimizando iconos del sitio...
Las publicaciones serán recocidas por un trabajo en segundo plano en sidekiq. Verás imágenes faltantes hasta que eso se complete.
Puedes acelerar el proceso ejecutando manualmente "rake posts:rebake_uncooked_posts"
Ejecutando el after_restore_hook...
Limpiando cosas...
Eliminando función del esquema discourse_functions
Eliminando el directorio tmp '/var/www/discourse/tmp/restores/db8015/2019-10-11-104940'...
Reanudando sidekiq...
Marcando la restauración como finalizada...
2

¿Sigue siendo este un problema, @sam?

3

Solo para aclarar, la reproducción es:

  • Crear un multisitio en un contenedor Docker

  • Hacer una copia de seguridad de uno de los multisitios

  • En un nuevo contenedor Docker, restaurarlo

  • Las subidas están en el lugar incorrecto

@kris.kotlarek ¿puedes reproducir esto en local y ver si puedes solucionarlo?

Sospecho que nos veremos afectados por esto en el futuro.

6

Solo el contenedor de destino necesita ser multisitio para reproducir esto.

  • Crear un foro en un contenedor de Docker
  • Crear una copia de seguridad
  • En un nuevo contenedor de Docker multisitio, restaurarla
  • Las cargas están en el lugar incorrecto
7

He dedicado un tiempo a este error y quería actualizaros con mis hallazgos. Básicamente, he confirmado todo lo que ya habíais dicho: el proceso de restauración es el siguiente:

migrate_database
reconnect_database
...
extract_uploads

El problema es que, tras la tarea de migración, reconnect_database no cambia a la base de datos deseada, sino que comienza a trabajar con la predeterminada.

Por lo tanto, este código es incorrecto:

def extract_uploads
  ...
  current_db_name = 
  RailsMultisite::ConnectionManagement.current_db # default
  optimized_images_exist = File.exist?(File.join(tmp_uploads_path, 'optimized'))

Una solución chapucera sería usar aquí @current_db, que aún contiene el nombre correcto, en lugar de RailsMultisite::ConnectionManagement.current_db, pero esto no resuelve el problema real de por qué reconnect_database no funciona correctamente.

Necesito profundizar más para encontrar el problema.

8

¿Estás seguro de que está ocurriendo después de la tarea de migración?

Este código

  migrate_database
  puts "Después de migrar, antes de reconectar #{RailsMultisite::ConnectionManagement.current_db}"
  reconnect_database

produce esto

Optimizando iconos del sitio... Hecho
Después de migrar, antes de reconectar default
Reconectando a la base de datos...

Pero cuando comentas la línea

Rake::Task['db:_dump'].invoke

en lib/tasks/db.rake

produce esto

Optimizando iconos del sitio... Hecho
Después de migrar, antes de reconectar db8015
Reconectando a la base de datos...
9

Tienes razón. Eliminé Rake::Task["db:migrate"].invoke de restorer.rb y obtuve la base de datos correcta durante todo el proceso. Estás un paso por delante de mí; mi plan ahora es entrar en la tarea de migración y ver qué paso está rompiendo el proceso. Gracias por señalar _dump; iré directamente allí para ver qué está ocurriendo dentro.

10

Dediqué un tiempo a investigarlo, pero finalmente encontré una solución :slight_smile:

11

¡Gracias!

Después de pensarlo un poco más, ¿qué significa realmente ejecutar db:dump en algo que no es la base de datos principal?

¿No debería simplemente omitir el comando db:dump si la base de datos no es la predeterminada?

16

Se fusionó la corrección, gracias por detectar ese problema. Se agregó ese comando de volcado porque había un problema con las migraciones multisitio. Creo que no debería importar qué base de datos estemos usando para volcar la estructura, ya que todos los multisitios deberían tener la misma estructura.