La reconstrucción falla en db:migrate con PG12

Ejecutar “./launcher rebuild app” falla en db:migrate. Tenga en cuenta que estamos usando PostgreSQL v12.

Esto mató nuestro foro. El contenedor de Docker volvió a iniciarse, pero el foro no. Por suerte, tomé una instantánea de la VM antes de actualizar, la estoy restaurando ahora.

Registro:

Tasks: TOP => db:migrate
(Ver el rastreo completo ejecutando la tarea con --trace)
I, [2022-04-14T15:20:51.896917 #1]  INFO -- : == 20220304162250 EnableUnaccentExtension: migrating =========
-- enable_extension("unaccent")

I, [2022-04-14T15:20:51.897218 #1]  INFO -- : Terminating async processes
I, [2022-04-14T15:20:51.897265 #1]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/12/bin/postmaster -D /etc/postgresql/12/main pid: 1710
I, [2022-04-14T15:20:51.897396 #1]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 1827
2022-04-14 15:20:51.897 UTC [1710] LOG:  received fast shutdown request
1827:signal-handler (1649949651) Received SIGTERM scheduling shutdown...
2022-04-14 15:20:51.900 UTC [1710] LOG:  aborting any active transactions
2022-04-14 15:20:51.902 UTC [1710] LOG:  background worker "logical replication launcher" (PID 1719) exited with exit code 1
2022-04-14 15:20:51.904 UTC [1714] LOG:  shutting down
1827:M 14 Apr 2022 15:20:51.913 # User requested shutdown...
1827:M 14 Apr 2022 15:20:51.914 * Saving the final RDB snapshot before exiting.
2022-04-14 15:20:51.965 UTC [1710] LOG:  database system is shut down
1827:M 14 Apr 2022 15:20:53.157 * DB saved on disk
1827:M 14 Apr 2022 15:20:53.157 # Redis is now ready to exit, bye bye...


FAILED
--------------------
Pups::ExecError: cd /var/www/discourse & su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 2118 exit 1>
Location of failure: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
2dcd9aeca614c9e06ef748f673eb68203db6eae5c445253b416d666663879d6d
==================== END REBUILD LOG ====================
Failed to rebuild app.

No son independientes y no hay PG externo. La actualización PG13 también falla (no destructivamente, a diferencia de la actualización de hoy) y, sinceramente, no recibí ayuda sobre cómo solucionarlo aquí.

Creo (obviamente no puedo comprobarlo) que solo teníamos un contenedor apareciendo en docker ps. ¿La instalación estándar ahora son 2 contenedores?

Esta extensión se convirtió en una extensión “confiable” en PostgreSQL 13+, donde puede ser habilitada por cualquier usuario.

Dado que está ejecutando una versión anterior de PostgreSQL, tendrá que encontrar una solución alternativa, instalando y habilitando esta extensión para el usuario de Discourse, y potencialmente intentando engañar a Discourse para que considere que esta extensión ya está instalada. O bien, migrar a la versión actual compatible de PostgreSQL.

1 me gusta

OK. En resumen, ya no admiten PG12. Sugiero publicarlo en el hilo de actualización de PG13 en algún lugar, y probablemente también en los anuncios de 2.9.0b4.

1 me gusta

Si te preocupa el tiempo de inactividad, una solución sería replicar el servidor en el nuevo host. Algo como community/archived/setting-up-postgres-hot-standby.md at master · GoogleCloudPlatform/community · GitHub. (Es posible que puedas encontrar instrucciones más recientes o algunas que tengan más sentido para ti…). Eso te permitiría migrar a la nueva base de datos mientras la antigua seguía funcionando. Pero eso está lejos de ser simple.

Es una buena idea, si fuera MySQL, MS-SQL u Oracle lo haría, pero dada mi falta de experiencia con PostgreSQL, probablemente aceptaría la interrupción.

1 me gusta

Mi restauración finalmente terminó, después de más de 4 horas. Y Discourse estaba lanzando errores 502. Esta instantánea se tomó antes de la actualización, así que esto es súper extraño.

De todos modos, al mirar los registros de nginx encontré este error

2022/04/14 19:36:21 [error] 493#493: *350 connect() failed (111: Connection refused) while connecting to upstream, client: 216.228.112.21, server: _, request: "POST /message-bus/15f7a893581d489e930634c8f3ed1134/poll?dlp=t HTTP/2.0", upstream: "http://127.0.0.1:3000/message-bus/15f7a893581d489e930634c8f3ed1134/poll?dlp=t", host: "forum.quartertothree.com", referrer: "https://forum.quartertothree.com/c/movies/8"

y luego en los registros de ruby,

/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.10.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require': cannot load such file -- /var/www/discourse/lib/freedom_patches/schema_cache_concurrency.rb (LoadError)

Efectivamente, este archivo era propiedad de root:root y tenía permisos 0000. Cambiarlo a discourse:root y 644 para que coincidiera con los otros archivos en ese directorio nos permitió volver a funcionar. ¡Uf!

¿Alguna idea de cómo se eliminó/modificó ese archivo? También tiene 0 bytes, muy extraño.


root@forum-app:/shared/log/rails# ls -la /var/www/discourse/lib/freedom_patches/schema_cache_concurrency.rb
-rw-r--r-- 1 discourse root 0 Feb 10 17:41 /var/www/discourse/lib/freedom_patches/schema_cache_concurrency.rb
1 me gusta

Este :point_up:

Ahora nos enfrentamos de nuevo a todo el problema de “espacio insuficiente porque la actualización requiere 300 GB”.

Buena suerte. Por lo que puedo decir, no hay una solución real aparte de restaurar una copia de seguridad en un host nuevo.

Gracias, pero básicamente está muerto.

Intenté hacer la “Restauración a una instalación limpia”, pero no funciona, PG no coopera. Intenté degradar la versión de Discourse y volver a PG12, pero entonces se convierte en un carnaval de luces con todos los plugins.

¿Intentaste reconstruir con esta plantilla de postgres en lugar de la predeterminada?

discourse_docker/templates/postgres.12.template.yml at main · discourse/discourse_docker · GitHub

1 me gusta

En primer lugar: Gracias por la ayuda.

Sí, cambié la plantilla, como parte de la estrategia de “esto no está funcionando” para poder volver a PG12 (aunque esto me hace cuestionar cómo voy a actualizar PG entonces :thinking: ).

Tuve que “cazar” un commit específico, pero aparentemente este es una apuesta segura: Version bump to v2.8.0.beta10 (#15382) · discourse/discourse@07c0104 · GitHub

Intenté con otros más recientes, pero el error enable_extension("unaccent") sigue presente, lo que implica que en esos commits ya se había hecho el cambio para depender de él.

Esperando el resultado de este intento.

Actualización: No, falló en la restauración durante la fase de “desempaquetado del volcado” y ahora está muerto de nuevo.

Hola, si tienes una copia de seguridad de Discourse, te sugiero que lo hagas en un servidor diferente para probarlo primero.

Creo que experimentaste este problema al actualizar una instancia de Discourse que estaba ejecutando una versión anterior.

Entonces, intenta instalar una copia de Discourse editando manualmente el archivo yml para usar la versión “stable” de Discourse y fija la versión de postgres a la 12.

Si la compilación tiene éxito, intenta restaurar la copia de seguridad. Esperemos que se restaure correctamente.
Si tiene éxito, cambia la plantilla de postgres 12 de nuevo a la plantilla de postgres predeterminada y comenta la etiqueta “stable” para que Discourse se reconstruya con las últimas pruebas superadas.

Creo que si la copia de seguridad es recuperable, debería poder sobrevivir a las actualizaciones de postgres y Discourse.

Avísame si encuentras algún problema.

2 Me gusta

Estoy prácticamente en el "limbo" ahora mismo. Probé tu sugerencia con PG12 y "Stable". No funciona, la restauración simplemente se detiene. Así que estoy borrando la máquina una vez más para intentarlo de nuevo desde cero porque ahora no hará la reconstrucción de la aplicación.

Mientras esa máquina intenta "volver a PG12", estoy intentando ver si puedo avanzar en la otra: Si intento actualizar PG con una instalación limpia, muere después de Creando funciones faltantes en el esquema discourse_functions... (empieza a devolver 500) y tail -f shared/data/log/var-log/postgres/current muestra que el contenedor de datos se está "moviendo", aunque solo está lleno de "errores" como este:

discourse@discourse ERROR:  la relación \"user_auth_tokens\" no existe en el carácter 34
discourse@discourse STATEMENT:  SELECT \"user_auth_tokens\".* FROM \"user_auth_tokens\" WHERE ((auth_token = 'XXXX=' OR
                                  prev_auth_token = 'XXXX=') AND rotated_at > '2022-03-09 10:21:44.051357') LIMIT 1
discourse@discourse ERROR:  la relación \"application_requests\" no existe en el carácter 41
discourse@discourse STATEMENT:  SELECT \"application_requests\".\"id\" FROM \"application_requests\" WHERE \"application_requests\".\"date\" = '2022-05-08' AND \"application_requests\".\"req_type\" = 0 LIMIT 1

Sin embargo, aunque Discourse esté muerto, la máquina se está utilizando, así que… ¿está funcionando pero solo tarda horas y horas? Porque la dejé funcionando durante más de 1 hora y nada cambió.

A estas alturas ya estoy pensando si esto no debería ir aquí, lol.

PD: Probé 2 copias de seguridad diferentes, ya que tomé 2 antes de la aventura.

No entiendo a qué te refieres con “simplemente se detiene”. ¿Te aparece algún error? ¿Experimentas una pantalla congelada? ¿Algo más?

1 me gusta

Eso no es bueno. ¿No pudiste restaurar tu copia de seguridad de la versión anterior de Discourse con PG12 a una nueva con PG13? ¿Puedes publicar los mensajes de error, etc.? Todo el mundo aquí me aseguró repetidamente que eso funcionaría.

1 me gusta

¿En qué sentido? ¿Hay algún error?

Esto ha resuelto el problema:

CREATE EXTENSION unaccent;

sin tener que actualizar PG

1 me gusta

Habría sido bueno saberlo hace un año, ¡pero gracias!

Para cualquiera que esté observando, finalmente hicimos una restauración completa a una instalación limpia en una nueva VM y funcionó bien.

3 Me gusta