Esta actualización recomendada falló y no recuperó mi foro después de romperlo. Ahora estoy ejecutando discourse-doctor para intentar arreglarlo y, si eso también falla, tomé una instantánea de la VM.
Salida:
2023-04-19 18:28:31.298 UTC [42] LOG: recibido solicitud de apagado rápido
2023-04-19 18:28:33.651 UTC [65] LOG: apagando
2023-04-19 18:28:33.974 UTC [42] LOG: el sistema de bases de datos está apagado
FALLÓ
--------------------
Pups::ExecError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' falló con retorno #<Process::Status: pid 59 exit 2>
Ubicación del fallo: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec falló con los parámetros "su postgres -c 'psql $db_name -c \\\"alter schema public owner to $db_user;\\\"'"
bootstrap falló con el código de salida 2
** FALLÓ EL ARRANQUE ** por favor desplácese hacia arriba y busque mensajes de error anteriores, puede haber más de uno.
./discourse-doctor puede ayudar a diagnosticar el problema.
c13e1ba313de8fc84f6e2fb0f88197a908803c39791283effb8c82f55b56b6dc
El comando salió con un estado distinto de cero 1
1.85usuario 1.84sistema 3:21.56transcurrido 1%CPU (0avgtext+0avgdata 36996maxresident)k
197608entradas+368salidas (1133major+96509minor)pagefaults 0swaps
Editar: Discourse-doctor nos ha puesto en marcha de nuevo.
Básicamente pedí esto, actualizando una hora después de esa notificación y siendo el primero en hacerlo. No hubo mucho estrés con esa instantánea de antemano, así que me sacrifiqué por el equipo, muchachos.
2023-04-19 18:28:26.755 UTC [45] LOG: la base de datos no se apagó correctamente; recuperación automática en curso
Si su base de datos no puede detenerse de forma segura en 60 segundos, lo que ocurrirá con bases de datos grandes con discos más lentos, entrará en este estado y fallará una reconstrucción si no puede recuperarse en 5 segundos (lo cual es raro ya que es grande/lenta).
Esto no tiene nada que ver con los cambios enumerados aquí, y es un problema en Discourse desde al menos 2016.
Ahh, gracias. Quizás debería esperar más tiempo para foros más grandes como el nuestro. Si simplemente detienes el proceso de la base de datos, necesitará revertir las transacciones después de reiniciarse y eso puede llevar mucho tiempo.
La terminología sobre beta es algo confusa. El panel de administración dice que estamos ejecutando beta, ¿hay algún otro lugar donde deberíamos haber mirado? Entiendo que beta es recomendable para discourse basándose en los anuncios de lanzamiento que desaconsejan el uso de la rama estable.
¿Cuándo se decidió que 60 segundos era un tiempo seguro para el apagado? ¿Cuántas instalaciones son ahora mucho más grandes de lo que era normal entonces?
Idealmente, esta espera de 60 segundos debería ser más una espera de bucle cerrado, con un límite. Parece que el límite debería ser mayor, si ahora hay muchas instancias que ahora son vulnerables.
Creo que lo vi hace al menos tanto tiempo como en 2016. Pero las cosas han cambiado. EDITAR: Aquí hay un nuevo commit.
No creo que muchas en una instalación estándar, ya que ha sido así casi desde el principio.
Uh, sí. Esa es una base de datos grande. Sospecho que pocas personas tienen una base de datos tan grande que no esté en RDS o al menos en un contenedor separado. Probablemente deberías considerar cambiar a una instalación de 2 contenedores.
Lo consideraremos, ¿el método de conmutación está documentado? ¿Y hay alguna otra ventaja que no proporcionaría el aumento del temporizador de 60 segundos?
Puedes construir un nuevo contenedor mientras el antiguo sigue en funcionamiento. No necesitas apagar la base de datos para construir un nuevo contenedor.
Ahora hay una ventana de 10 minutos para apagar postgres, lo que debería resolver tu problema actual. Una vez que hagas una reconstrucción más, tendrás los 10 minutos en lugar de uno.
Ese tipo acaba de crear una instancia de dos contenedores completamente nueva y luego restauró desde una copia de seguridad. Definitivamente no haremos eso sin una buena razón, solo tuve que hacerlo para evitar los requisitos de espacio en disco de la actualización de PG13 hace unos 2 meses.
¡Ahora sí, esa era inevitablemente inevitable! Más allá de la base de datos, también necesitábamos actualizar desde la 18.04LTS, que ya no tiene soporte.
Si hay documentación sobre cómo hacerlo sin una reconstrucción completa desde cero, entonces restaurar copias de seguridad definitivamente lo consideraremos.