¿Cuál es la salida de:
tail /var/discourse/shared/standalone/log/var-log/postgres/current
root@ubuntu-s-1vcpu-1gb-nyc3-01:/var/discourse# tail /var/discourse/shared/standalone/log/var-log/postgres/current
INNER JOIN (SELECT topic_id, GREATEST(COUNT(*), 1) AS count
FROM posts
WHERE created_at >= '2025-02-01 04:44:07.521324'
AND deleted_at IS NULL
AND NOT hidden
AND post_type = 1
AND user_id <> -1
GROUP BY topic_id) c ON tt.topic_id = c.topic_id
WHERE tt.topic_id = top_topics.topic_id
AND tt.daily_posts_count <> c.count
root@ubuntu-s-1vcpu-1gb-nyc3-01:/var/discourse# vim shared/standalone/log/var-log/postgres/current
root@ubuntu-s-1vcpu-1gb-nyc3-01:/var/discourse#
root@ubuntu-s-1vcpu-1gb-nyc3-01:/var/discourse#
root@ubuntu-s-1vcpu-1gb-nyc3-01:/var/discourse# cat shared/standalone/log/var-log/postgres/current
2025-02-02 04:42:42.765 UTC [542] LOG: starting PostgreSQL 13.18 (Debian 13.18-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2025-02-02 04:42:42.768 UTC [542] LOG: listening on IPv4 address "0.0.0.0", port 5432
2025-02-02 04:42:42.768 UTC [542] LOG: listening on IPv6 address "::", port 5432
2025-02-02 04:42:42.779 UTC [542] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2025-02-02 04:42:42.804 UTC [561] LOG: database system was interrupted; last known up at 2025-02-02 04:37:10 UTC
2025-02-02 04:42:43.209 UTC [561] LOG: database system was not properly shut down; automatic recovery in progress
2025-02-02 04:42:43.221 UTC [561] LOG: redo starts at 2/DB0B59D0
2025-02-02 04:42:43.264 UTC [561] LOG: invalid record length at 2/DB22D540: wanted 24, got 0
2025-02-02 04:42:43.264 UTC [561] LOG: redo done at 2/DB22D518
2025-02-02 04:42:43.347 UTC [542] LOG: database system is ready to accept connections
2025-02-02 04:43:49.036 UTC [1273] discourse@discourse LOG: duration: 584.511 ms statement: UPDATE topic_hot_scores thsOrig
SET
recent_likes = COALESCE(new_values.likes_count, 0),
recent_posters = COALESCE(new_values.unique_participants, 0),
recent_first_bumped_at = COALESCE(new_values.first_bumped_at, ths.recent_first_bumped_at)
FROM
topic_hot_scores ths
LEFT OUTER JOIN
(
SELECT
t.id AS topic_id,
COUNT(DISTINCT p.user_id) AS unique_participants,
(
SELECT COUNT(distinct pa.user_id)
FROM post_actions pa
JOIN posts p2 ON p2.id = pa.post_id
WHERE p2.topic_id = t.id
AND p2.post_type = 1
AND p2.deleted_at IS NULL
AND p2.user_deleted = false
AND pa.post_action_type_id = 2 -- action_type for 'like'
AND pa.created_at >= '2025-01-26 04:43:48.403603'
AND pa.deleted_at IS NULL
) AS likes_count,
MIN(p.created_at) AS first_bumped_at
FROM
topics t
JOIN
posts p ON t.id = p.topic_id
WHERE
p.created_at >= '2025-01-26 04:43:48.403603'
AND t.archetype <> 'private_message'
AND t.deleted_at IS NULL
AND p.deleted_at IS NULL
AND p.user_deleted = false
AND t.created_at <= '2025-02-02 04:43:48.403603'
AND t.bumped_at >= '2025-01-26 04:43:48.403603'
AND p.created_at < '2025-02-02 04:43:48.403603'
AND p.created_at >= '2025-01-26 04:43:48.403603'
AND p.post_type = 1
GROUP BY
t.id
) AS new_values
ON ths.topic_id = new_values.topic_id
WHERE thsOrig.topic_id = ths.topic_id
2025-02-02 04:44:04.629 UTC [1273] discourse@discourse LOG: duration: 153.751 ms statement: WITH x AS (SELECT
u.id user_id,
SUM(CASE WHEN p.id IS NOT NULL AND t.id IS NOT NULL AND ua.action_type = 2 THEN 1 ELSE 0 END) likes_received,
SUM(CASE WHEN p.id IS NOT NULL AND t.id IS NOT NULL AND ua.action_type = 1 THEN 1 ELSE 0 END) likes_given,
COALESCE((SELECT COUNT(topic_id) FROM topic_views AS v WHERE v.user_id = u.id AND v.viewed_at > '2025-02-01 04:44:04.456893'), 0) topics_entered,
COALESCE((SELECT COUNT(id) FROM user_visits AS uv WHERE uv.user_id = u.id AND uv.visited_at > '2025-02-01 04:44:04.456893'), 0) days_visited,
COALESCE((SELECT SUM(posts_read) FROM user_visits AS uv2 WHERE uv2.user_id = u.id AND uv2.visited_at > '2025-02-01 04:44:04.456893'), 0) posts_read,
SUM(CASE WHEN t2.id IS NOT NULL AND ua.action_type = 4 THEN 1 ELSE 0 END) topic_count,
SUM(CASE WHEN p.id IS NOT NULL AND t.id IS NOT NULL AND ua.action_type = 5 THEN 1 ELSE 0 END) post_count
FROM users AS u
LEFT OUTER JOIN user_actions AS ua ON ua.user_id = u.id AND COALESCE(ua.created_at, '2025-02-01 04:44:04.456893') > '2025-02-01 04:44:04.456893'
LEFT OUTER JOIN posts AS p ON ua.target_post_id = p.id AND p.deleted_at IS NULL AND p.post_type = 1 AND NOT p.hidden
LEFT OUTER JOIN topics AS t ON p.topic_id = t.id AND t.archetype = 'regular' AND t.deleted_at IS NULL AND t.visible
LEFT OUTER JOIN topics AS t2 ON t2.id = ua.target_topic_id AND t2.archetype = 'regular' AND t2.deleted_at IS NULL AND t2.visible
LEFT OUTER JOIN categories AS c ON t.category_id = c.id
WHERE u.active
AND u.silenced_till IS NULL
AND u.id > 0
GROUP BY u.id)
UPDATE directory_items di SET
likes_received = x.likes_received,
likes_given = x.likes_given,
topics_entered = x.topics_entered,
days_visited = x.days_visited,
posts_read = x.posts_read,
topic_count = x.topic_count,
post_count = x.post_count
FROM x
WHERE
x.user_id = di.user_id AND
di.period_type = 5 AND (
di.likes_received <> x.likes_received OR
di.likes_given <> x.likes_given OR
di.topics_entered <> x.topics_entered OR
di.days_visited <> x.days_visited OR
di.posts_read <> x.posts_read OR
di.topic_count <> x.topic_count OR
di.post_count <> x.post_count )
2025-02-02 04:44:07.657 UTC [1400] discourse@discourse LOG: duration: 135.675 ms statement: UPDATE top_topics
SET daily_posts_count = c.count
FROM top_topics tt
INNER JOIN (SELECT topic_id, GREATEST(COUNT(*), 1) AS count
FROM posts
WHERE created_at >= '2025-02-01 04:44:07.521324'
AND deleted_at IS NULL
AND NOT hidden
AND post_type = 1
AND user_id <> -1
GROUP BY topic_id) c ON tt.topic_id = c.topic_id
WHERE tt.topic_id = top_topics.topic_id
AND tt.daily_posts_count <> c.count
Si esa es la salida que ve después de detener su contenedor app, podría significar que algo todavía se está conectando a la base de datos. Consulte pg_stat_activity para ver si puede aislarlo. Puede intentar detener estos servicios en el contenedor app para ayudar a reducir el problema.
./launcher start app
./launcher enter app
sv stop nginx
sv stop unicorn
1 me gusta
Acabo de comprobar y solo veo
2025-02-02 12:06:05.808 UTC [48] LOG: received smart shutdown request
¿Así que supongo que la base de datos no se apagó correctamente y se cerró forzosamente después del tiempo de espera?
Eso parece. ¿Podrías intentar seguir los pasos de esta publicación anterior y ver si hay otras conexiones de cliente a la base de datos? Idealmente, deberías detener cualquier otra aplicación que se conecte a la base de datos antes de detener el contenedor app.
Alternativamente, puedes intentar terminar todas las sesiones de base de datos establecidas y detener rápidamente el servicio postgres (idealmente antes de que las aplicaciones cliente se reconecten) y luego intentar una reconstrucción después de confirmar un cierre limpio de la base de datos a partir de los registros. Sin embargo, te recomiendo encarecidamente que primero identifiques el impacto en tus aplicaciones cliente listadas en pg_stat_activity antes de terminar sus conexiones.
Aquí tienes un comando de ejemplo que puedes ejecutar para terminar las conexiones de cliente y detener postgres desde dentro del contenedor app después de detener nginx y unicorn primero.
sudo -u postgres psql -c "SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE pid <> pg_backend_pid();" && sv stop postgres
3 Me gusta
Solo una rápida actualización: hemos aplicado un parche que debería devolver un mensaje de error más apropiado si la base de datos no se cerró correctamente.
5 Me gusta
¡Muchas gracias! Detener manualmente los servicios dentro del contenedor aparentemente funcionó, y pude reconstruir el doble contenedor para la actualización (con las variables de locale ajustadas como se discutió anteriormente; nota al margen: revisé la documentación de instalación y no creo que mencionen las locales; tal vez esta sería una buena adición).
Desafortunadamente, el análisis de los procesos problemáticos no fue concluyente. Lo único que veo son cosas relacionadas con Postgres como WalWriter, AutoVacuum, etc. La única pista que tengo es que cuando reinicio el sistema y también después de cambios en los índices en las actualizaciones, típicamente veo una alta carga de CPU para postgres durante aproximadamente media hora.
Y cuando revisé pg_stat_activity hoy después del reinicio, vi dos consultas de larga duración (al menos si mi comprensión de las columnas es correcta):
SELECT "posts"."id" FROM "posts" INNER JOIN "topics" ON "topics"."deleted_at" IS NULL AND "topics"."id" = "posts"."topic_id" LEFT JOIN post_search_data ON post_id = posts.id WHERE "posts"."deleted_at" IS NULL AND (posts.raw != '') AND (topics.deleted_at IS NULL) AND (post_search_data.locale IS NULL OR post_search_data.locale != 'de' OR post_search_data.version != 5) ORDER BY posts.id DESC LIMIT 20000
y
SELECT "optimized_images".* FROM "optimized_images" WHERE "optimized_images"."upload_id" = 13 AND "optimized_images"."height" = 32 AND "optimized_images"."width" = 32 LIMIT 1
Después de los 30 minutos mencionados, la primera aparentemente se completó y la carga de CPU de postgres ahora es normal.
No estoy seguro de por qué estas dos consultas tardan tanto y aún menos por qué la segunda todavía aparece en pg_stat_activity después de más de una hora, pero potencialmente consultas de larga duración como estas impidieron que el servicio de postgres se apagara correctamente al intentar reconstruirlo antes.
Si tienes alguna pista aquí, te lo agradecería mucho. Pero potencialmente esto también es algo que podría ir en otro hilo (si es así, házmelo saber y editaré esta publicación).
Capturas de pantalla relacionadas:
2 Me gusta
¡Me alegra saber que funcionó! Ahora he incluido esos pasos en OP.
Sobre la alta carga de CPU de postgres al iniciar, parece que has estado experimentando el mismo problema incluso antes de la actualización de la versión de PG. Si es así, no está relacionado con la actualización. (De todos modos, se recomienda ejecutar un vacuum después de una actualización de la versión de PG. Consulta las tareas posteriores a la actualización.)
El mal rendimiento de la base de datos/consultas podría ser causado por una miríada de problemas. Podrían ser índices corruptos en la base de datos, un host infra-provisionado, un error en Discourse que introdujo una consulta problemática, etc. Podría ser útil abrir un tema de Support para eso.
4 Me gusta
Se dividieron 6 publicaciones en un nuevo tema: Sitio fuera de línea después de la reconstrucción (4 de febrero de 2025)
13 publicaciones se dividieron en un nuevo tema: Fallo al actualizar PostgreSQL desde China
Nada parece funcionar para mí.
He iniciado un tema Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
¿Alguien puede sugerir cómo solucionarlo?
2 Me gusta
En un par de sitios en servidores antiguos hoy, he necesitado ejecutar
chown -R 101:104 /var/discourse/shared/standalone/postgres_*
Estoy bastante seguro de que estuvieron involucrados varios años y versiones antiguas de Ubuntu (que tenían diferentes IDs de usuario).
2 Me gusta
Eso es interesante. Actualicé un sitio que no se había actualizado en aproximadamente un año y todo salió perfectamente. Estaba en la v3.2.0.beta4+253.
2 Me gusta
Deseo actualizar mi instancia de Discourse, pero quiero dejar mi base de datos en Postgres 13. ¿Es esto posible?
1 me gusta
Sí, consulta esta parte de las instrucciones oficiales:
3 Me gusta
¿Hay instrucciones aquí para una instancia de dos contenedores? Al hojear, no las veo y la búsqueda no las encontró.
1 me gusta
Esto ahora está cubierto en “Configuración del contenedor de datos” arriba.
1 me gusta
Este comando no cambia nada
1 me gusta
¿Cómo puedo comprobar en qué versión de PostgreSQL estoy?
Editar: olvídalo, lo he resuelto.
Tengo un par de servidores con la configuración regional en_GB.UTF-8 y, siguiendo las instrucciones al principio del hilo, no llego muy lejos:
./launcher stop app
Se detectó la arquitectura x86_64.
+ /usr/bin/docker stop -t 600 app
app
discourse@sands:/var/discourse$ docker run --rm --entrypoint=/bin/bash -e LANG='en_GB.UTF-8' -v /var/discourse/shared/standalone/postgres_data:/var/lib/postgresql/13/data -v /var/discourse/shared/standalone/postgres_data_new:/var/lib/postgresql/15/data tianon/postgres-upgrade:13-to-15 -c 'sed -i "s/^# $LANG/$LANG/" /etc/locale.gen && locale-gen && apt-get update && apt-get install -y postgresql-13-pgvector postgresql-15-pgvector && docker-upgrade'
Generando configuraciones regionales (esto puede tardar un poco)...
en_GB.UTF-8... hecho
en_US.UTF-8... hecho
Generación completa.
Obtenido:1 http://deb.debian.org/debian bookworm InRelease [151 kB]
Obtenido:2 http://deb.debian.org/debian bookworm-updates InRelease [55.4 kB]
Obtenido:3 http://deb.debian.org/debian-security bookworm-security InRelease [48.0 kB]
Obtenido:4 http://apt.postgresql.org/pub/repos/apt bookworm-pgdg InRelease [129 kB]
Obtenido:5 http://deb.debian.org/debian bookworm/main amd64 Packages [8,792 kB]
Obtenido:6 http://deb.debian.org/debian bookworm-updates/main amd64 Packages [13.5 kB]
Obtenido:7 http://deb.debian.org/debian-security bookworm-security/main amd64 Packages [243 kB]
Obtenido:8 http://apt.postgresql.org/pub/repos/apt bookworm-pgdg/main amd64 Packages [360 kB]
Obtenido:9 http://apt.postgresql.org/pub/repos/apt bookworm-pgdg/13 amd64 Packages [2,571 B]
Obtenido:10 http://apt.postgresql.org/pub/repos/apt bookworm-pgdg/15 amd64 Packages [2,584 B]
Descargados 9,798 kB en 2s (4,547 kB/s)
Leyendo listas de paquetes...
Leyendo listas de paquetes...
Construyendo árbol de dependencias...
Leyendo la información de estado...
Se instalarán los siguientes paquetes NUEVOS:
postgresql-13-pgvector postgresql-15-pgvector
0 actualizados, 2 instalados, 0 para eliminar y 0 no actualizados.
Se necesitan descargar 597 kB de archivos.
Después de esta operación, se usarán 1,540 kB adicionales de espacio en disco.
Obtenido:1 http://apt.postgresql.org/pub/repos/apt bookworm-pgdg/main amd64 postgresql-13-pgvector amd64 0.8.0-1.pgdg120+1 [297 kB]
Obtenido:2 http://apt.postgresql.org/pub/repos/apt bookworm-pgdg/main amd64 postgresql-15-pgvector amd64 0.8.0-1.pgdg120+1 [300 kB]
debconf: retrasando la configuración de paquetes, ya que apt-utils no está instalado
Descargados 597 kB en 0s (1,274 kB/s)
Seleccionando el paquete no seleccionado anteriormente postgresql-13-pgvector.
(Leyendo la base de datos ... 13891 archivos y directorios actualmente instalados.)
Preparando para desempaquetar .../postgresql-13-pgvector_0.8.0-1.pgdg120+1_amd64.deb ...
Desempaquetando postgresql-13-pgvector (0.8.0-1.pgdg120+1) ...
Seleccionando el paquete no seleccionado anteriormente postgresql-15-pgvector.
Preparando para desempaquetar .../postgresql-15-pgvector_0.8.0-1.pgdg120+1_amd64.deb ...
Desempaquetando postgresql-15-pgvector (0.8.0-1.pgdg120+1) ...
Configurando postgresql-13-pgvector (0.8.0-1.pgdg120+1) ...
Configurando postgresql-15-pgvector (0.8.0-1.pgdg120+1) ...
Procesando disparadores para postgresql-common (267.pgdg120+1) ...
debconf: no se puede inicializar el frontend: Dialog
debconf: (TERM no está establecido, por lo que el frontend de diálogo no es utilizable).
debconf: recurriendo al frontend: Readline
debconf: no se puede inicializar el frontend: Readline
debconf: (este frontend requiere una tty de control).
debconf: recurriendo al frontend: Teletype
Construyendo diccionarios de PostgreSQL a partir de paquetes myspell/hunspell instalados...
Eliminando archivos de diccionario obsoletos:
Realizando comprobaciones de consistencia
-----------------------------
Comprobando versiones de clúster ok
*fallo*
Consulte las últimas líneas de "/var/lib/postgresql/15/data/pg_upgrade_output.d/20250207T165542.724/log/pg_upgrade_server.log" para
la causa probable del fallo.
la conexión al servidor en el socket "/var/lib/postgresql/.s.PGSQL.50432" falló: No existe tal archivo o directorio
¿Está el servidor ejecutándose localmente y aceptando conexiones en ese socket?
no se pudo conectar al postmaster de origen iniciado con el comando:
"/usr/lib/postgresql/13/bin/pg_ctl" -w -l "/var/lib/postgresql/15/data/pg_upgrade_output.d/20250207T165542.724/log/pg_upgrade_server.log" -D "/var/lib/postgresql/13/data" -o "-p 50432 -b -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/var/lib/postgresql'" start
Fallo, saliendo
¿Alguien más ha tenido este problema? ¿Alguien tiene alguna sugerencia?
3 Me gusta