PostgreSQL atascado durante la reconstrucción

Instalación
1

Hola a todos,

Estoy teniendo un problema con el inicio de PostgreSQL cuando intenté reconstruir mi aplicación, y espero recibir ayuda.

Aquí está el registro, se ha quedado atascado en este estado durante más de 30 minutos.

Status: Image is up to date for discourse/base:2.0.20240825-0027
docker.io/discourse/base:2.0.20240825-0027
/usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups.rb
/usr/local/bin/pups --stdin
I, [2024-08-26T17:16:15.344712 #1]  INFO -- : Reading from stdin
I, [2024-08-26T17:16:15.357924 #1]  INFO -- : File > /etc/service/postgres/run  chmod: +x  chown:
I, [2024-08-26T17:16:15.362740 #1]  INFO -- : File > /etc/service/postgres/log/run  chmod: +x  chown:
I, [2024-08-26T17:16:15.367767 #1]  INFO -- : File > /etc/runit/3.d/99-postgres  chmod: +x  chown:
I, [2024-08-26T17:16:15.372845 #1]  INFO -- : File > /root/install_postgres  chmod: +x  chown:
I, [2024-08-26T17:16:15.377501 #1]  INFO -- : File > /root/upgrade_postgres  chmod: +x  chown:
I, [2024-08-26T17:16:15.377876 #1]  INFO -- : Replacing data_directory = '/var/lib/postgresql/13/main' with data_directory = '/shared/postgres_data' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.378854 #1]  INFO -- : Replacing (?-mix:#?listen_addresses *=.*) with listen_addresses = '*' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.379386 #1]  INFO -- : Replacing (?-mix:#?synchronous_commit *=.*) with synchronous_commit = $db_synchronous_commit in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.379835 #1]  INFO -- : Replacing (?-mix:#?shared_buffers *=.*) with shared_buffers = $db_shared_buffers in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.380263 #1]  INFO -- : Replacing (?-mix:#?work_mem *=.*) with work_mem = $db_work_mem in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.380761 #1]  INFO -- : Replacing (?-mix:#?default_text_search_config *=.*) with default_text_search_config = '$db_default_text_search_config' in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.381203 #1]  INFO -- : Replacing (?-mix:#?checkpoint_segments *=.*) with checkpoint_segments = $db_checkpoint_segments in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.381901 #1]  INFO -- : Replacing (?-mix:#?logging_collector *=.*) with logging_collector = $db_logging_collector in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.382352 #1]  INFO -- : Replacing (?-mix:#?log_min_duration_statement *=.*) with log_min_duration_statement = $db_log_min_duration_statement in /etc/postgresql/13/main/postgresql.conf
I, [2024-08-26T17:16:15.382802 #1]  INFO -- : Replacing (?-mix:^#local +replication +postgres +peer$) with local replication postgres  peer in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.383231 #1]  INFO -- : Replacing (?-mix:^host.*all.*all.*127.*$) with host all all 0.0.0.0/0 md5 in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.383604 #1]  INFO -- : Replacing (?-mix:^host.*all.*all.*::1\/128.*$) with host all all ::/0 md5 in /etc/postgresql/13/main/pg_hba.conf
I, [2024-08-26T17:16:15.384079 #1]  INFO -- : > if [ -f /root/install_postgres ]; then
  /root/install_postgres &
  rm -f /root/install_postgres
elif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then
  socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
fi

2024/08/26 17:16:15 socat[28] E connect(, AF=1 "/shared/postgres_run/.s.PGSQL.5432", 36): Connection refused
I, [2024-08-26T17:16:15.452500 #1]  INFO -- : Generating locales (this might take a while)...
Generation complete.

I, [2024-08-26T17:16:15.453058 #1]  INFO -- : > HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
I, [2024-08-26T17:16:15.455944 #1]  INFO -- : Terminating async processes
2024-08-26 17:16:15.500 UTC [30] LOG:  starting PostgreSQL 13.16 (Debian 13.16-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2024-08-26 17:16:15.501 UTC [30] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2024-08-26 17:16:15.501 UTC [30] LOG:  listening on IPv6 address "::", port 5432
2024-08-26 17:16:15.507 UTC [30] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-08-26 17:16:15.516 UTC [31] LOG:  database system was interrupted; last known up at 2024-08-26 17:10:28 UTC
2024-08-26 17:16:15.769 UTC [31] LOG:  database system was not properly shut down; automatic recovery in progress
2024-08-26 17:16:15.774 UTC [31] LOG:  redo starts at 18F/E62D1458
2024-08-26 17:16:15.774 UTC [31] LOG:  invalid record length at 18F/E62D1490: wanted 24, got 0
2024-08-26 17:16:15.774 UTC [31] LOG:  redo done at 18F/E62D1458
2024-08-26 17:16:15.809 UTC [30] LOG:  database system is ready to accept connections```
2

Así que no se apagó limpiamente e intentó arreglar las cosas, y cree que lo hizo.

Quizás sal de él con control-c y mira si puedes ejecutar ./launcher start app para que el contenedor anterior vuelva a funcionar.

Si funciona, entonces puedes intentar de nuevo ./launcher stop app y luego reconstruir.

3 Me gusta
3

He estado teniendo el mismo problema intentando reconstruir en los últimos días. No puedo hacer que Discourse funcione o se reconstruya sin problemas.

Intenté usar la capacidad de inicio/parada y no pareció funcionar. La VM en sí también se ha reiniciado un par de veces. Simplemente sigue colgado en esa línea sobre la base de datos lista para aceptar conexiones.

4

Control-C no funcionó e intenté muchas cosas diferentes, incluido volver a versiones anteriores, pero tan pronto como intenté reconstruir, se atascó en el mismo lugar.

5

¿Cuánta RAM tienes? ¿Tu conexión de red es lenta?

6

para mi problema…tengo mucha RAM…8 GB. La red está bien.

7

4 GB de RAM, revisé la red, el uso del disco, el uso de la CPU, el uso de la RAM, todo parece estar bien.

8

Logré avanzar más. En /var/discourse/ en mi servidor, hice checkout del commit b1108913820edd27f869634d0fc654639758889a. Este commit es de hace unos días y no tiene estos tres commits (1, 2, 3 en el historial de discourse_docker. Sospecho que uno de estos cambios es la razón del problema de postgres colgado.

De todos modos, finalmente logré que la aplicación volviera a funcionar. Fue una experiencia horrible, jaja.

3 Me gusta
11

Mismo problema aquí al actualizar de 3.3.0 a 3.3.1. La actualización se queda atascada en la misma línea de registro (el sistema de base de datos está listo para aceptar conexiones).

Reiniciar ayuda o simplemente matar el proceso de actualización y ejecutar ./launcher start app. Se muestra la nueva versión 3.3.1. Pero no estoy seguro de si este es un procedimiento sensato.

13

Así que son cuatro personas con un problema, creo.

¿Los que tuvieron problemas estaban en ARM o en Intel?

1 me gusta
14

Esa es una gran pregunta.

Acabo de hacer una instalación limpia en una nueva VM de Digital Ocean y luego ejecuté una reconstrucción y funcionó perfectamente.

15

Estoy usando Intel.

La forma en que resolví el problema fue que tuve que iniciar una nueva instancia y hacer una instalación limpia, y restaurar la copia de seguridad, luego la reconstrucción funciona bien.

También tengo una copia de seguridad de una versión que funciona (que es una versión un poco más antigua), pero tan pronto como actualicé a la última versión a través de la reconstrucción, encontré el mismo problema, así que sospecho que hay algo introducido con una confirmación reciente y que solo interrumpe la actualización de la versión antigua a la nueva.

1 me gusta
16

Maldición.

Hmm. Veré si tengo un sitio que no me importe si se cae.

Supongo que tienes una instalación estándar estándar de 1 contenedor. Veré si puedo encontrar una de esas.

17

Solo estoy actualizando esto ya que también he visto este problema desde el commit anterior. He intentado todo lo anterior para resolver el problema.

2 Me gusta
18

x86. Estoy en Ubuntu Bionic para el sistema operativo anfitrión… quizás eso sea importante. No estoy seguro de cuál es el sistema operativo de los demás.

19

Ya ha pasado más de un año desde el fin de su vida útil (EOL). https://ubuntu.com/blog/ubuntu-18-04-eol-for-devices.

No es demasiado pronto para iniciar una nueva máquina virtual y migrar allí.

4 Me gusta
20

Solo información adicional para ayudar a investigar el problema.

Estoy viendo esto en un host que ejecuta Ubuntu 18.04.6, pero otro host también se actualizó hoy con la misma versión de Ubuntu y la reconstrucción de Discourse progresó normalmente.

Voy a actualizar Ubuntu en el host afectado y veré si esto ayuda. Mantendré a todos informados.

2 Me gusta
21

Para los afectados, ¿pueden ejecutar el comando ls -lahn /var/discourse/shared/standalone/ | grep -E \"postgres|redis\" y decirme si la salida difiere de la que se muestra a continuación?

drwxr-xr-x  2  101 104 4.0K Aug 29 01:33 postgres_backup
drwx------ 19  101 104 4.0K Aug 29 01:42 postgres_data
drwxrwxr-x  3  101 104 4.0K Aug 29 01:42 postgres_run
drwxr-xr-x  2  103 106 4.0K Aug 29 01:38 redis_data
1 me gusta
22 
# ls -lahn /var/discourse/shared/standalone/ | grep -E \"postgres|redis\" 
drwxr-xr-x  2  101 104 4.0K Dec 26  2019 postgres_backup
drwx------ 19  101 104 4.0K Aug 28 03:59 postgres_data
drwxrwxr-x  5  101 104 4.0K Aug 28 03:59 postgres_run
drwxr-xr-x  2  103 106 4.0K Aug 29 03:59 redis_data
2 Me gusta
23

Salida de la VM con problemas de reconstrucción:

drwxr-xr-x  2  101 104 4.0K Jun 15  2020 postgres_backup
drwx------ 19  101 104 4.0K May  3  2022 postgres_data
drwxrwsr-x  5  101 104 4.0K May  3  2022 postgres_run
drwxr-xr-x  2  103 106 4.0K May  3  2022 redis_data

Solo una nota, algo ligeramente diferente en mi caso.
La reconstrucción se quedó atascada en El sistema de base de datos está listo para aceptar conexiones, como han visto otros. Tuve que reiniciar la VM y ejecutar ./launcher start app para iniciar los Foros. Sin embargo, cuando Discourse volvió a estar en línea, la versión de Discourse permaneció en la versión anterior 3.3.0.beta4-dev.

No puedo realizar la actualización de Ubuntu hoy, pero mantendré a todos informados cuando pueda y si la reconstrucción tiene éxito.

Actualicé nuestra instancia de desarrollo a Ubuntu 20.6 hoy y la reconstrucción/actualización fue exitosa a Discourse 3.4.0.beta2-dev. Sin embargo, este fue el host que también se reconstruyó sin problemas en Ubuntu 18.4 ayer.