Quel est le résultat 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 c’est le résultat que vous voyez après avoir arrêté votre conteneur app, cela peut signifier que quelque chose se connecte toujours à la base de données. Vérifiez pg_stat_activity pour voir si vous pouvez l’isoler. Vous pouvez essayer d’arrêter ces services dans le conteneur app pour aider à réduire le problème.
./launcher start app
./launcher enter app
sv stop nginx
sv stop unicorn
1 « J'aime »
Je viens de vérifier et je ne vois que
2025-02-02 12:06:05.808 UTC [48] LOG: received smart shutdown request
Donc, je suppose que la base de données ne s’est pas arrêtée correctement et a été arrêtée de force après expiration du délai ?
Il semblerait. Pourriez-vous essayer de suivre les étapes décrites dans ce message précédent et voir s’il existe d’autres connexions client à la base de données ? Idéalement, vous devriez arrêter toutes les autres applications qui se connectent à la base de données avant d’arrêter le conteneur app.
Alternativement, vous pouvez essayer de terminer toutes les sessions de base de données établies et d’arrêter rapidement le service postgres (idéalement avant que les applications clientes ne se reconnectent), puis tenter une nouvelle reconstruction après avoir confirmé un arrêt propre de la base de données à partir des journaux. Cependant, je vous recommande vivement d’identifier d’abord l’impact sur vos applications clientes listées dans pg_stat_activity avant de terminer leurs connexions.
Voici une commande d’exemple que vous pouvez exécuter pour terminer les connexions client et arrêter postgres depuis le conteneur app après avoir arrêté nginx et unicorn en premier.
sudo -u postgres psql -c "SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE pid <> pg_backend_pid();" && sv stop postgres
3 « J'aime »
Juste une petite mise à jour : nous avons appliqué un correctif qui devrait afficher un message d’erreur plus approprié si la base de données ne s’est pas arrêtée proprement.
5 « J'aime »
Alors, merci beaucoup ! Arrêter manuellement les services à l’intérieur du conteneur a apparemment fait l’affaire, et j’ai pu reconstruire le double conteneur pour la mise à niveau (avec les variables de locale ajustées comme discuté ci-dessus - note annexe : j’ai vérifié la documentation d’installation et je ne pense pas qu’elle mentionne les locales ; ce serait peut-être un bon ajout).
Malheureusement, l’analyse des processus problématiques n’a pas été concluante. La seule chose que je vois, ce sont des éléments liés à Postgres comme WalWriter, AutoVacuum, etc. Le seul indice que j’ai, c’est que lorsque je redémarre le système et aussi après des changements d’index lors des mises à jour, je constate généralement une charge CPU élevée pour postgres pendant environ une demi-heure.
Et quand j’ai vérifié pg_stat_activity aujourd’hui après le redémarrage, j’ai vu deux requêtes de longue durée (du moins si ma compréhension des colonnes est correcte) :
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
et
SELECT "optimized_images".* FROM "optimized_images" WHERE "optimized_images"."upload_id" = 13 AND "optimized_images"."height" = 32 AND "optimized_images"."width" = 32 LIMIT 1
Après les 30 minutes mentionnées ci-dessus, la première a apparemment été terminée et la charge CPU de postgres est maintenant normale.
Je ne suis pas sûr pourquoi ces deux requêtes prennent autant de temps et encore moins pourquoi la seconde apparaît toujours dans pg_stat_activity après plus d’une heure, mais potentiellement de telles requêtes de longue durée ont empêché le service postgres de s’arrêter correctement lors de la tentative de reconstruction plus tôt.
Si vous avez une piste ici, ce serait très apprécié. Mais potentiellement, c’est aussi quelque chose qui pourrait faire l’objet d’un autre fil de discussion (si c’est le cas, faites-le moi savoir, et j’éditerai ce post).
Captures d’écran associées :
2 « J'aime »
Je suis content d’apprendre que cela a fonctionné ! J’ai maintenant inclus ces étapes dans le OP.
Concernant la charge CPU élevée de postgres au démarrage, il semble que vous ayez rencontré le même problème avant même la mise à jour de la version de PG. Si c’est le cas, cela n’est pas lié à la mise à jour. (Quoi qu’il en soit, il est recommandé d’exécuter un vacuum après une mise à jour de version de PG. Voir les tâches post-mise à jour.)
De mauvaises performances de la base de données/des requêtes peuvent être causées par une multitude de problèmes. Il pourrait s’agir d’index corrompus dans la base de données, d’un hôte sous-provisionné, d’un bug dans Discourse qui a introduit une requête problématique, etc. Il pourrait être utile d’ouvrir un sujet de Support pour cela.
4 « J'aime »
6 messages ont été déplacées vers un nouveau sujet : Site hors ligne après reconstruction (4 février 2025)
13 publications ont été séparées dans un nouveau sujet : La mise à jour de PostgreSQL échoue depuis la Chine
Pour moi, rien ne semble fonctionner.
J’ai lancé un sujet Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
Quelqu’un peut-il suggérer comment le réparer ?
2 « J'aime »
Sur quelques sites sur de vieux serveurs aujourd’hui, j’ai dû faire un
chown -R 101:104 /var/discourse/shared/standalone/postgres_*
Je suis à peu près sûr que plusieurs années et d’anciennes versions d’Ubuntu (qui avaient des identifiants utilisateur différents) étaient impliquées.
2 « J'aime »
C’est intéressant. J’ai mis à jour un site qui n’avait pas été mis à jour depuis environ un an et tout s’est déroulé sans problème. Il était à la version v3.2.0.beta4+253.
2 « J'aime »
Je souhaite mettre à jour mon instance Discourse, mais je veux conserver ma base de données sur Postgres 13. Est-ce possible ?
1 « J'aime »
Oui, consultez cette partie des instructions officielles :
3 « J'aime »
Y a-t-il des instructions ici pour une instance à deux conteneurs ? En parcourant rapidement, je ne vois rien et une recherche n’a rien trouvé.
1 « J'aime »
Ceci est maintenant couvert dans « Configuration du conteneur de données » ci-dessus.
1 « J'aime »
Cette commande ne change rien
1 « J'aime »
Comment puis-je vérifier sur quelle version de PostgreSQL je me trouve ?
Edit : oubliez, j’ai trouvé.
J’ai quelques serveurs avec la locale en_GB.UTF-8 et en suivant les instructions en haut du fil, je n’avance pas beaucoup :
./launcher stop app
x86_64 arch detected.
+ /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'
Generating locales (this might take a while)...
en_GB.UTF-8... done
en_US.UTF-8... done
Generation complete.
Get:1 http://deb.debian.org/debian bookworm InRelease [151 kB]
Get:2 http://deb.debian.org/debian bookworm-updates InRelease [55.4 kB]
Get:3 http://deb.debian.org/debian-security bookworm-security InRelease [48.0 kB]
Get:4 http://apt.postgresql.org/pub/repos/apt bookworm-pgdg InRelease [129 kB]
Get:5 http://deb.debian.org/debian bookworm/main amd64 Packages [8,792 kB]
Get:6 http://deb.debian.org/debian bookworm-updates/main amd64 Packages [13.5 kB]
Get:7 http://deb.debian.org/debian-security bookworm-security/main amd64 Packages [243 kB]
Get:8 http://apt.postgresql.org/pub/repos/apt bookworm-pgdg/main amd64 Packages [360 kB]
Get:9 http://apt.postgresql.org/pub/repos/apt bookworm-pgdg/13 amd64 Packages [2,571 B]
Get:10 http://apt.postgresql.org/pub/repos/apt bookworm-pgdg/15 amd64 Packages [2,584 B]
Fetched 9,798 kB in 2s (4,547 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
The following NEW packages will be installed:
postgresql-13-pgvector postgresql-15-pgvector
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 597 kB of archives.
After this operation, 1,540 kB of additional disk space will be used.
Get:1 http://apt.postgresql.org/pub/repos/apt bookworm-pgdg/main amd64 postgresql-13-pgvector amd64 0.8.0-1.pgdg120+1 [297 kB]
Get: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: delaying package configuration, since apt-utils is not installed
Fetched 597 kB in 0s (1,274 kB/s)
Selecting previously unselected package postgresql-13-pgvector.
(Reading database ... 13891 files and directories currently installed.)
Preparing to unpack .../postgresql-13-pgvector_0.8.0-1.pgdg120+1_amd64.deb ...
Unpacking postgresql-13-pgvector (0.8.0-1.pgdg120+1) ...
Selecting previously unselected package postgresql-15-pgvector.
Preparing to unpack .../postgresql-15-pgvector_0.8.0-1.pgdg120+1_amd64.deb ...
Unpacking postgresql-15-pgvector (0.8.0-1.pgdg120+1) ...
Setting up postgresql-13-pgvector (0.8.0-1.pgdg120+1) ...
Setting up postgresql-15-pgvector (0.8.0-1.pgdg120+1) ...
Processing triggers for postgresql-common (267.pgdg120+1) ...
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
Building PostgreSQL dictionaries from installed myspell/hunspell packages...
Removing obsolete dictionary files:
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
*failure*
Consult the last few lines of "/var/lib/postgresql/15/data/pg_upgrade_output.d/20250207T165542.724/log/pg_upgrade_server.log" for
the probable cause of the failure.
connection to server on socket "/var/lib/postgresql/.s.PGSQL.50432" failed: No such file or directory
Is the server running locally and accepting connections on that socket?
could not connect to source postmaster started with the command:
"/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
Failure, exiting
Quelqu’un d’autre a-t-il rencontré ce problème ? Quelqu’un a-t-il des suggestions ?
3 « J'aime »