Implosión después de la actualización 2.7beta7

[BryanV (Bryan Van de ven)]

Hola a todos,

Hemos estado ejecutando una instancia autoalojada de Discourse en https://discourse.bokeh.org durante varios años. En términos generales, ha sido extremadamente estable y ha requerido casi ningún esfuerzo de mantenimiento; en particular, realizar actualizaciones suele ser un proceso sin incidentes que se completa perfectamente sin ningún problema.

Sin embargo, hoy, después de una actualización a la versión 2.7beta7 (que pareció completarse sin problemas), nuestro sitio ha colapsado por completo. Funcionó a trompicones durante un tiempo con páginas mal renderizadas y errores en la consola de JS, pero después de intentar un retorno a la versión anterior, la interfaz de usuario quedó completamente inutilizable. Al iniciar sesión en el droplet, también he intentado lo siguiente sin éxito:

Reconstrucción

./launcher rebuild app

Esto ha fallado de varias maneras en varios intentos.

Discourse Doctor

./discourse-doctor

Restauración

./launcher enter app
discourse restore <archivo de respaldo>

Esto falló.

Borrado total

También intenté hacer un “borrado” y luego restaurar:

./launcher stop app
./launcher destroy app
rm -r /var/discourse/shared/standalone/

Después de esto, al menos pude lograr que una reconstrucción tuviera éxito, lo que llevó a un estado de “instalación nueva”, por ejemplo: “¡Felicidades, has instalado Discourse!”.

Así que ahora he intentado ejecutar discourse restore nuevamente, pero esto también ha fallado.

EXCEPCIÓN: 1 publicación no se ha vuelto a mapear a la nueva URL de carga en S3. La migración a S3 falló para la base de datos 'default'. /var/www/discourse/lib/file_store/to_s3_migration.rb:131:in `raise_or_log' /var/www/discourse/lib/file_store/to_s3_migration.rb:86:in `migration_successful?' /var/www/discourse/lib/file_store/to_s3_migration.rb:357:in `migrate_to_s3' /var/www/discourse/lib/file_store/to_s3_migration.rb:65:in `migrate' /var/www/discourse/lib/file_store/s3_store.rb:240:in `copy_from' /var/www/discourse/lib/backup_restore/uploads_restorer.rb:62:in `restore_uploads' /var/www/discourse/lib/backup_restore/uploads_restorer.rb:44:in `restore' /var/www/discourse/lib/backup_restore/restorer.rb:62:in `run' script/discourse:145:in `restore' /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.1.0/lib/thor/command.rb:27:in `run' /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.1.0/lib/thor/invocation.rb:127:in `invoke_command' /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.1.0/lib/thor.rb:392:in `dispatch' /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.1.0/lib/thor/base.rb:485:in `start' script/discourse:286:in `' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli/exec.rb:63:in `load' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli/exec.rb:63:in `kernel_load' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli/exec.rb:28:in `run' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli.rb:494:in `exec' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli.rb:30:in `dispatch' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli.rb:24:in `start' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/exe/bundle:49:in `block in ' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/friendly_errors.rb:130:in `with_friendly_errors' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/exe/bundle:37:in `' /usr/local/bin/bundle:23:in `load' /usr/local/bin/bundle:23:in `' Intentando volver a la versión anterior... Volviendo a la versión anterior... Limpieza de archivos... Eliminando funciones del esquema discourse_functions... Eliminando el directorio temporal '/var/www/discourse/tmp/restores/default/2021-04-23-235404'... Marcando la restauración como finalizada... Notificando a 'system' sobre el final de la restauración... ¡Finalizado! [FALLÓ]

Lo extraño es que, durante la restauración, el sitio parecía estar volviendo a la normalidad, mostrando contenido antiguo. Luego ocurrió el fallo y ahora no se muestra nada; las cuentas han desaparecido, etc.

Realmente necesito cualquier orientación o sugerencia. Tenemos copias de seguridad diarias que llegan hasta una semana atrás (y más atrás en Glacier si es necesario). Eliminamos una categoría no utilizada hace unos días; ¿podría eso ser la causa del problema? Intentaré con una copia de seguridad más antigua para ver, pero cualquier indicación sobre un proceso de restauración infalible será bienvenido.

[BryanV (Bryan Van de ven)]

Una copia de seguridad más antigua no ayudó. Durante la restauración, todo parece “más o menos bien”:

Todo parece correcto hasta el final, momento en el que inmediatamente aparece esto:

Por cierto, ¿la copia de seguridad no incluye las publicaciones que fueron importadas originalmente desde una lista de correo, pero que llevan años en el sitio de Discourse? Teníamos 24 mil publicaciones, no 5 mil, antes de esto.

[BryanV (Bryan Van de ven)]

¿Existe alguna forma de reconstruir la aplicación en una versión anterior de Discourse, por ejemplo, en la 2.7beta6?

[BryanV (Bryan Van de ven)]

Alternativamente, supongo que literalmente hay solo una publicación que está causando algún problema.

EXCEPCIÓN: 1 publicación no se ha vuelto a mapear a la nueva URL de carga de S3. La migración de S3 falló para la base de datos ‘default’.

¿Es posible encontrar esta publicación y simplemente eliminarla o quitarla?

[pfaffman (Jay Pfaffman)]

¿Tienes imágenes en S3?

[BryanV (Bryan Van de ven)]

@pfaffman Sí, tenemos imágenes en S3.

[pfaffman (Jay Pfaffman)]

Hmm. Bueno, quizás solo haya un mensaje roto. Supongo que necesitarías restaurar la base de datos, arreglarla y luego reconstruir el archivo de copia de seguridad con la nueva base de datos. Pero es muy difícil saberlo con certeza.

[BryanV (Bryan Van de ven)]

¿Hay instrucciones en algún lugar sobre cómo hacer eso? ¿Cómo puedo determinar cuál es el único mensaje roto?

Edición: ¿Alternativamente, hay alguien con experiencia que pueda ser contratado para servicios?

[Don]

¿Tienes una copia de seguridad o una instantánea (snapshot) reciente de tu droplet que puedas restaurar?

[BryanV (Bryan Van de ven)]

¿Tienes una copia de seguridad reciente de un droplet o una instantánea de la que puedas restaurar?

Lamentablemente, no. Las copias de seguridad de DigitalOcean son solo semanales, y yo había configurado copias de seguridad diarias de Discourse en S3, manteniendo una semana de datos recientes y un año de antigüedad en Glacier. Dada mi experiencia positiva previa con muchas actualizaciones de Discourse, pensé que eso sería suficiente y mejor (y además había realizado restauraciones de prueba exitosas antes).

[Benjamin_D (Benjamin Decotte)]

@pfaffman

En app.yml, descomenta

#version: tests-passed

digamos
version: 94301854938a0b36dd64666fb7a7c8406544a781, que es el commit justo antes del aumento de la versión beta.

[BryanV (Bryan Van de ven)]

Bueno, en realidad es una actualización. En un arrebato de desesperación, simplemente aborté forzosamente el script de restauración durante la etapa de

Sincronizando archivos a S3
antes de que se quejara sobre la 1 publicación defectuosa e iniciara un revertimiento.

El sitio en realidad volvió a estar en línea y era accesible en modo seguro. Desactivé el componente de tema “COPIAR Y PEGAR” para bloques de código que, al parecer, ahora es completamente incompatible con la última versión beta. Después de eso, el sitio parece estar mayormente en funcionamiento, incluso sin el modo seguro. Pero:

• ¿Hay alguna acción recomendada para asegurarse de que todo esté lo más “limpio” posible? Por ejemplo, volver a subir los activos a S3 y “rehornar”? ¿Dónde están las mejores y más actuales instrucciones para eso?

EDITO: Por lo que puedo ver, todo ha vuelto a la normalidad. Las imágenes en publicaciones antiguas se están cargando correctamente desde S3/CDN. Supongo que entonces mi pregunta es: si estamos subiendo imágenes a S3, ¿debería esta opción estar desmarcada?

Incluir cargas en copias de seguridad programadas. Desactivar esto solo hará una copia de seguridad de la base de datos.

Creía que tenerla marcada ofrecía una capa adicional de redundancia, pero parece que es la fuente de todos estos problemas durante la restauración.

[Don]

@BryanV

Incluir las subidas en las copias de seguridad programadas. Si desactivas esta opción, solo se realizará una copia de seguridad de la base de datos.

La última vez que cambié a otro proveedor de alojamiento, también tuve problemas con S3 al restaurar. Por eso pregunté al respecto y la respuesta fue afirmativa. Si almacenas tus imágenes en S3, debes hacer la copia de seguridad sin incluir las subidas; solo la base de datos. Sin embargo, no sé si esta es la solución adecuada en tu caso. Si decides probarlo, crea antes una instantánea.

Puedes ver más información aquí: Restore a backup from the command line - #28

Yo lo probé y funcionó perfectamente sin ningún problema.

[pfaffman (Jay Pfaffman)]

Puedo ayudar. El lunes, o antes si hay pago por riesgo.

Puedes Contact Us - Literate Computing a nuestro S3, la dirección de correo electrónico que aparece al final de la página.

[BryanV (Bryan Van de ven)]

@pfaffman ¡Gracias! El sitio parece estar funcionando con total normalidad ahora mismo, pero no rechazaría una revisión rápida o una verificación de sentido común en tu momento de conveniencia, si estás dispuesto. De todos modos, he anotado tu información de contacto comercial para cualquier emergencia futura.

Aquí dejo un informe retrospectivo, por si es útil para alguien más.

---

RESUMEN

Tras una actualización (exitosa), un componente de tema no oficial incompatible rompió la interfaz de usuario del sitio. En ese momento no se sabía esto, por lo que se inició el proceso de restauración desde copia de seguridad, pero encontró problemas debido a una configuración menos que ideal.

DETALLES

1. Se inició una actualización a 2.7beta7, que se completó con éxito.

2. Sin embargo, tras la actualización, la interfaz de usuario del sitio quedó gravemente comprometida: los cuerpos de las publicaciones estaban completamente ausentes, la navegación superior (incluyendo usuario/iniciar sesión) también desapareció por completo y la consola de JS reportó errores.

   1. La razón resultó ser un componente de tema de terceros incompatible para copiar y pegar bloques de código, pero esto no se sabía en ese momento.

   2. Tampoco se conocía en ese momento la posibilidad de entrar en modo seguro. De haberse sabido, se habrían evitado los problemas restantes.

3. Se logró acceso a \\admin mediante navegación directa y se intentó un revertir. Esto cerró sesión inmediatamente al usuario y no parecía haber forma de volver a iniciar sesión con la interfaz rota.

4. Se inició sesión en el Droplet de DO para comenzar una restauración manual con el último archivo tar de copia de seguridad desde S3.

5. Muchos intentos de restauración fallaron cerca del paso final, tras subir los activos de S3, debido a un error en una sola publicación.

   1. Esto es evidentemente porque las restauraciones que intentan volver a subir activos a S3 pueden ser inestables (varios informes de esto en Meta).
   2. Sin embargo, no era necesario hacer copias de seguridad de los activos de carga, ¡ya que ya estaban almacenados en S3!

6. Durante uno de los muchos intentos de restauración, el sitio también se borró para intentar desde una “pizarra limpia”, por lo que los revertidos tras los fallos de restauración ahora devolvían un sitio vacío.

7. Finalmente, en una apuesta desesperada, ejecuté la restauración y aborté manualmente el script durante la carga a S3 (justo antes del fallo y el revertido).

8. El sitio volvió a estar en línea, pero mostraba los problemas de interfaz anteriores. Sin embargo, ahora se conocía y usaba el modo seguro, y el sitio funcionaba con normalidad con los plugins y temas desactivados.

9. Se eliminaron todos los plugins y temas no oficiales (incluido el componente de “copiar y pegar”), tras lo cual el sitio funcionó con normalidad.

10. Se verificó que las imágenes cargadas anteriormente seguían cargándose, y lo hacían desde el CDN de S3.

Sospecho que la carga final y el “rebake” no eran necesarios, ya que los activos seguían estando en S3 y las publicaciones no necesitaban actualizarse para usar nuevas URL.

No estoy seguro de qué pasos de restauración, si alguno, se pasaron por alto tras abortar el script, pero hasta ahora nadie ha encontrado problemas con el sitio en su estado actual.

LECCIONES / ACCIONES

• Empezar con modo seguro para diagnosticar problemas en el futuro.
• Desactivar la configuración para incluir cargas en las copias de seguridad (se sugerirá a Discourse que advierta sobre esta situación).
• Eliminar todos los plugins y componentes de tema no oficiales.
• Sugerir activar la nueva función integrada de copiar bloques de código.
• Habilitar las copias de seguridad semanales de imágenes de Digital Ocean como respaldo para la recuperación.

[merefield (Robert)]

@BryanV

un componente de tema no oficial o un plugin incompatible

¿Componente de tema o plugin? ¿Podrías informar al autor?

[BryanV (Bryan Van de ven)]

@merefield Parece que ya se conoce, por eso supe de la posibilidad.

https://meta.discourse.org/t/copy-option-for-code-blocks-in-discourse/60961

[BryanV (Bryan Van de ven)]

Si pudiera ofrecer una sugerencia sobre el proceso de restauración, sería incluir algunas opciones para hacerlo más resistente. Por ejemplo, si lo único que impide una restauración exitosa es un solo mensaje defectuoso, pulsaría la tecla Y en un abrir y cerrar de ojos si se me preguntara: “¿Eliminar el mensaje defectuoso?”.

[gerhard (Gerhard Schlager)]

Eso estará en una de las próximas betas de 2.8. Lamentablemente, aún no está listo para la próxima versión 2.7.

Lamento no haber visto tu llamado de ayuda antes. Aquí hay un consejo para todos los demás que tienen problemas con las restauraciones cuando las cargas están almacenadas en S3: extrae el archivo dump.sql.gz de tu copia de seguridad y renómbralo. Por ejemplo, si la copia de seguridad original se llamaba discourse-2020-10-09-133921-v20201007124955.tar.gz, el archivo resultante debería llamarse discourse-2020-10-09-133921-v20201007124955.sql.gz. Restaurar ese archivo debería funcionar.