Proceso de restauración cancelado en el paso de migración de cargas a S3

Soporte
1

He tenido problemas al intentar ejecutar una restauración en nuestra instancia de Discourse de Staging. Staging está ejecutando v2.4.0.beta1 +36. ¿Alguna idea de dónde podría estar el fallo o dónde buscar? ¡Gracias de antemano!

A continuación se muestra el final de la salida del registro:

[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] Migrando la base de datos...
[2019-07-16 20:08:16] Reconectando a la base de datos...
[2019-07-16 20:08:16] Recargando la configuración del sitio...
[2019-07-16 20:08:16] Desactivando el envío de correos electrónicos para usuarios que no son del personal...
[2019-07-16 20:08:16] Limpiando la caché de emojis...
[2019-07-16 20:08:16] Desactivando el modo de solo lectura...
[2019-07-16 20:08:16] Limpiando la caché del tema
[2019-07-16 20:08:22] Extrayendo archivos cargados...
[2019-07-16 20:08:40] Migrando archivos cargados a S3...
[2019-07-16 20:08:46] ¡El proceso de restauración fue cancelado!
[2019-07-16 20:08:46] Intentando revertir...
[2019-07-16 20:08:46] Revertiendo...
[2019-07-16 20:08:47] Limpiando cosas...
[2019-07-16 20:08:47] Eliminando el directorio temporal '/var/www/discourse/tmp/restores/default/2019-07-16-200516'...
[2019-07-16 20:08:48] Reanudando sidekiq...
[2019-07-16 20:08:48] Marcando la restauración como finalizada...
2

¿Hay algún problema con tu configuración de S3?

3

¿Ves más salida al ejecutar discourse restore BACKUP_FILENAME desde la línea de comandos?

4

Lo revisaré a continuación y te informaré. Gracias.

5

A continuación se muestra la salida tras ejecutar discourse restore NOMBRE_ARCHIVO_RESERVA desde la línea de comandos. Cualquier comentario será bienvenido, ¡gracias!

Desactivando el envío de correos electrónicos para usuarios no pertenecientes al personal...

Limpiando la caché de emojis...

Desactivando el modo de solo lectura...

Limpiando la caché del tema

Extrayendo archivos subidos...

Migrando archivos subidos a S3...

Verificando si la base de datos predeterminada ya fue migrada...

524 de 9474 archivos subidos no fueron migrados a S3. La migración a S3 falló para la base de datos 'default'.

321 publicaciones no fueron reasignadas a la nueva URL de subida en S3. La migración a S3 falló para la base de datos 'default'.

Buscando archivos subidos faltantes en: default

Corrigiendo archivos subidos faltantes: 

..........................................................................................................

Faltan 116 archivos subidos de publicaciones.

Faltan 116 archivos subidos.

106 de 116 son archivos subidos con el esquema antiguo.

98 de 83342 publicaciones se ven afectadas.

rake posts:missing_uploads identificó 98 problemas. La migración a S3 falló para la base de datos 'default'.

No hay publicaciones que requieran regeneración

Migrando archivos subidos a S3 para 'default'...

Algunos archivos subidos no fueron migrados al nuevo esquema. Ejecute estos comandos en la consola de Rails

SiteSetting.migrate_to_new_scheme = true

Jobs::MigrateUploadScheme.new.execute(nil)

¡El proceso de restauración fue cancelado!

Intentando revertir...

Revertiendo...

Limpiando archivos...

Eliminando el directorio temporal '/var/www/discourse/tmp/restores/default/2019-07-22-172918'...

Reactivando sidekiq...

Marcando la restauración como finalizada...

Notificando a 'system' sobre el final de la restauración...

¡Finalizado!

[FALLÓ]

Restauración completada.
6

Ese es un problema conocido. Lo arreglaré mañana.

8

Siguiendo con este asunto para ver si la corrección se ha implementado. ¡Gracias!

9

No, aún no está solucionado. Pero, como solución temporal, podrías desactivar temporalmente la configuración del sitio enable_s3_uploads antes de crear la copia de seguridad.

10

Haciendo seguimiento a la solución a largo plazo para este desafío. ¡Gracias!

11

¿Se resolvió esto alguna vez? Estoy experimentando el mismo problema al intentar migrar a un nuevo servidor. Voy a probar el método alternativo.

12

Esto me ha afectado recientemente en una migración relativamente grande.

13

Estoy bastante seguro de que acabo de verse afectado por esto también; creo que esto debería marcarse como un error.
(Si es diferente, siéntete libre de moverlo a un nuevo tema separado).

Es bastante importante que la restauración de copias de seguridad funcione.

Ten en cuenta que la razón del fallo no es obvia al usar la interfaz de administración y hacer clic en Restaurar junto al nombre de la copia de seguridad; obtienes:

...
Migrando cargas a S3...
¡El proceso de restauración fue cancelado!
...

Completar la restauración mediante la línea de comandos te proporciona más detalles:

discourse enter app
discourse restore example-net-2020-01-02-033557-v20191219112000.tar.gz
...
Reconectando a la base de datos...
Recargando la configuración del sitio...
Deshabilitando correos salientes para usuarios no pertenecientes al personal...
Limpiando la caché de emojis...
Deshabilitando el modo de solo lectura...
Limpiando la caché del tema
Extrayendo cargas...
Reasignando cargas...
Reasignando '//forum-example-net.s3.dualstack.eu-west-2.amazonaws.com/' a '/uploads/default/'
optimized_images=3
uploads=1
Migrando cargas a S3...
Verificando si 'default' ya fue migrado...
6 de 12 cargas no han sido migradas a S3. La migración a S3 falló para la base de datos 'default'.
1 publicación no fue reasignada a la nueva URL de carga de S3. La migración a S3 falló para la base de datos 'default'.
Buscando cargas faltantes en: default

No faltan cargas de publicaciones.
  Por favor, proporciona las siguientes variables de entorno
    - DISCOURSE_S3_BUCKET
    - DISCOURSE_S3_REGION
    y bien
    - DISCOURSE_S3_ACCESS_KEY_ID
    - DISCOURSE_S3_SECRET_ACCESS_KEY
    o
    - DISCOURSE_S3_USE_IAM_PROFILE
¡El proceso de restauración fue cancelado!
Intentando revertir...
Revertiendo...
Limpiando cosas...
Eliminando la función del esquema discourse_functions
Eliminando el directorio temporal '/var/www/discourse/tmp/restores/default/2020-01-06-222212'...
Reanudando sidekiq...
Marcando la restauración como finalizada...
Notificando a 'system' sobre el final de la restauración...
¡Finalizado!
[FAILED]
Restauración completada.

Agregué un pequeño código de depuración en uploads.rake justo antes de “Por favor, proporciona las siguientes variables de entorno” para volcar las variables de entorno:

puts "ENV: " + ENV.inspect

ENV no contenía ninguna variable DISCOURSE_S3_* configurada.

¿Hay alguna razón significativa por la que esto no esté extrayendo estos datos de la configuración?}

14

Creo que la idea es que, si tienes archivos subidos en S3, harás una copia de seguridad solo de la base de datos y, por lo tanto, no fallará porque no incluirá las subidas.

15

Totalmente, pero eso no ayuda cuando la copia de seguridad que tienes es una que incluye las subidas.

Para ser claro: no es críticamente importante para mí en este momento; puedo comentar las líneas problemáticas y completar la restauración, pero otros no pueden.

16

De acuerdo. Además, mover todas las cargas a S3 es una tarea bastante complicada y requiere un CDN de S3.

17

No es necesario convertir esto en un bug. Está en mi lista de tareas y ya he dedicado una gran cantidad de tiempo a refactorizar el proceso de restauración, agregar muchas pruebas y hacerlo más confiable. Haré algunos ajustes más para reducir la probabilidad de que la restauración en S3 falle y para mostrar más información en la interfaz de administración.

18

Por lo que sé, la copia de seguridad y restauración ha sido rediseñada, pero acabo de descubrir que esto sigue siendo un problema.
Un intento en beta11 de restaurar una copia de seguridad con enable s3 uploads activado sigue fallando con:

[2020-02-18 09:51:38] Restaurando archivos subidos, esto puede tardar un poco...
[2020-02-18 09:51:38] EXCEPCIÓN: Por favor, proporcione las siguientes variables de entorno:
  - DISCOURSE_S3_BUCKET
  - DISCOURSE_S3_REGION
  y bien
  - DISCOURSE_S3_ACCESS_KEY_ID
  - DISCOURSE_S3_SECRET_ACCESS_KEY
  o
  - DISCOURSE_S3_USE_IAM_PROFILE

[2020-02-18 09:51:38] /var/www/discourse/lib/file_store/to_s3_migration.rb:34:in `s3_options_from_env'
19

¿Entonces las cargas a S3 están habilitadas en la base de datos, pero no las copias de seguridad en S3?

20

Correcto, esto se trata de la migración de cargas.

Las credenciales de acceso a S3 están presentes en la base de datos restaurada, por lo que no es necesario exigir que también estén en una variable de entorno.

Proporcionar las variables de entorno también provoca un error:

Restaurando cargas, esto puede tardar un poco...
Verificando si db8015 ya fue migrada...
200 de 206 cargas no han sido migradas a S3. La migración a S3 falló para la base de datos 'db8015'.
5 publicaciones no fueron remapeadas a la nueva URL de carga de S3. La migración a S3 falló para la base de datos 'db8015'.
Ninguna publicación requiere rebakeado.
Migrando cargas a S3 para 'db8015'...
Subiendo archivos a S3...
 - Listando archivos locales
 => 21 archivos
 - Listando archivos en S3
. => 16 archivos
 - Sincronizando archivos con S3
.....................
Actualizando las URLs en la base de datos...
Eliminando imágenes optimizadas antiguas...
Marcando todas las publicaciones que contienen lightboxes para rebakeado...
5 publicaciones fueron marcadas para un rebakeado
EXCEPCIÓN: 183 de 206 cargas no han sido migradas a S3. La migración a S3 falló para la base de datos 'db8015'.
/var/www/discourse/lib/file_store/to_s3_migration.rb:127:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:74:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:350:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:61:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:203:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:48:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:30:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:58:in `run'
script/discourse:143:in `restore'

No tengo idea de por qué esto está fallando.

La mayoría de las cargas estaban en S3, por lo que los mensajes “200 de 206 cargas no han sido migradas a S3” y “183 de 206 cargas no han sido migradas a S3” son incorrectos. La cantidad de 21 archivos locales es correcta, y hay aproximadamente 200 cargas en S3 (podrían ser 206 también). No reconozco ninguno de los otros números (183, 16).

Tampoco sé por qué el proceso de restauración está intentando mover más cargas a S3. ¿No debería simplemente tomar las imágenes locales de la copia de seguridad y dejar las cargas en S3 sin tocarlas? ¿O estoy pasando por alto algo?

Al final, terminé modificando manualmente la configuración enable_s3_uploads en el volcado de la base de datos para establecerla en false, pero eso provocó que todo fuera remapeado nuevamente a local. Y como había algunas imágenes que aún estaban en local, requirió mucho trabajo determinar cuáles debían ser remapeadas a S3 y cuáles no.

Todo esto se realizó en la versión 2.4.0 beta11.

21

La combinación de cargas locales con cargas almacenadas en S3 no es compatible. Sí, sé que es posible terminar en tal situación cuando alguien cambia de local a S3 y no migra las cargas existentes a S3, pero eso es otra historia…

La restauración de una copia de seguridad siempre incluye el remapeo de cargas si el sistema detecta cambios que afectan las URL de carga. Esto incluye cambiar entre modo independiente y multisitio, cambiar entre cargas locales y S3, así como cambios en la configuración de S3 y CDN. Todas las cargas se restauran en la ubicación correcta según la configuración, ya sea localmente o en S3.

De vez en cuando nos encontramos con copias de seguridad donde el remapeo automático y la migración a S3 fallan por varias razones. Puedes esperar ver más mejoras a principios del ciclo de desarrollo de la versión 2.5.