Vous n'êtes pas identifié(e).
Pages : 1
Bonjour,
Nous rencontrons régulièrement des pics de lag entre notre serveur primaire et notre standby (hot standby en pg 9.6). J'ai l’impression que ce lag est créé par des requêtes "SELECT" très longues qui tournent sur la standby (plusieurs dizaines de minutes). Pendant tout le temps où ces requêtes s'exécutent,les wal ne semblent pas appliqués par la standby.
Extrait du pg_stat_replication sur le primaire. Tout est ok mais le "replay" ne consomment pas les wals.
usename | application_name | client_addr | delta_sent_mb | delta_write_mb | delta_flush_mb | delta_replay_mb
-------------+------------------+-------------+---------------+----------------+----------------+-----------------
replication | walreceiver | ************ | 0.00 | 0.00 | 0.00 | 91167.93
Est ce que c'est "normal" ?
Merci
Hors ligne
Ça peut., ça dépend de votre paramétrage:
- est-ce que le standby a hot_standby_feedback activé ? (sinon le primaire va supprimer des enregistrements lors de vacuum qui pourraient encore être nécessaires au standby... et donc le standby va devoir arrêter la réplication le temps que ces requetes se terminent)
- que vaut max_standby_streaming_delay ? c'est le temps maximum que le standby va accepter d'attendre avant de commencer à tuer les requêtes qui bloquent la réapplication des journaux
Marc.
Hors ligne
postgres=# show hot_standby_feedback ;
hot_standby_feedback
----------------------
off
(1 row)
postgres=# show max_standby_streaming_delay ;
max_standby_streaming_delay
-----------------------------
30s
(1 row)
Vu le paramétrage, je ne comprends pas comment je peux avoir du lag
Hors ligne
Etes vous sûr que la réplication est en pause, pas juste très ralentie? Sans connaître votre serveur, il se peut que la sur-consommation de ressources par la requête en écriture ralentisse simplement l'application des journaux... Vous pouvez déjà surveiller pg_last_wal_replay_lsn() sur le standby pour vérifier que c'est en pause et pas très ralenti...
Marc.
Hors ligne
Tant que j'y pense, vérifiez aussi pg_is_wal_replay_paused() sur le standby quand ça se produit… sait on jamais, un développeur retors 
Marc.
Hors ligne
Etes vous sûr que la réplication est en pause, pas juste très ralentie? Sans connaître votre serveur, il se peut que la sur-consommation de ressources par la requête en écriture ralentisse simplement l'application des journaux... Vous pouvez déjà surveiller pg_last_wal_replay_lsn() sur le standby pour vérifier que c'est en pause et pas très ralenti...
C'est possible qu'elle soit ralentie, nous avons une forte charge en écriture sur le serveur primaire, la quantité de wal absorbée n'arrivait surement pas à compenser ce qui arrivaient. Et du coup, le lag montait constamment.
Hors ligne
Tant que j'y pense, vérifiez aussi pg_is_wal_replay_paused() sur le standby quand ça se produit… sait on jamais, un développeur retors
J'ai eu le doute aussi...et j'ai lancé
postgres=# select pg_is_in_recovery();
pg_is_in_recovery
-------------------
t
(1 row)
Hors ligne
pg_is_in_recovery va être à true, normal. Par contre, pg_is_wal_replay_paused, c'est savoir si y aurait pas un petit malin qui met la réplication en pause... je le sais, parce que je l'ai déjà fait (pour passer des pg_dump parallélisé sur un standby par exemple )
Sinon, le replay est toujours plus lent que la génération: sur le serveur primaire, il y a plusieurs processus qui insèrent en même temps dans le WAL. Sur le standby, il y a un seul processus qui rejoue le tout. On peut aussi avoir les disques qui ont du mal à suivre ou d'autres choses. Donc vérifiez que la réplication n'est pas effectivement en pause ou bloquée par quelque chose, et si elle avance, il faut trouver la source de contention... cpu ou disque probablement
Marc.
Hors ligne
pg_is_in_recovery va être à true, normal. Par contre, pg_is_wal_replay_paused, c'est savoir si y aurait pas un petit malin qui met la réplication en pause... je le sais, parce que je l'ai déjà fait (pour passer des pg_dump parallélisé sur un standby par exemple
Sinon, le replay est toujours plus lent que la génération: sur le serveur primaire, il y a plusieurs processus qui insèrent en même temps dans le WAL. Sur le standby, il y a un seul processus qui rejoue le tout. On peut aussi avoir les disques qui ont du mal à suivre ou d'autres choses. Donc vérifiez que la réplication n'est pas effectivement en pause ou bloquée par quelque chose, et si elle avance, il faut trouver la source de contention... cpu ou disque probablement
Je vais chercher... merci pour le retour
Hors ligne
Il me reste quand même des questions au sujet de la réplication.
De ce que je comprends donc, quand un select est lancé côté standby, PG ne réapplique plus les wal si une modification (update/delete/insert) altère la vue du début du sélect (pour gérer la cohérence). Il attend max_standby_streaming_delay ou alors, c'est géré par hot_standby_feedback.
C'est bien cela ?
Hors ligne
Non, c'est un peu plus compliqué que ça. Quand on fait un update sous PostgreSQL, on n'écrase pas l'enregistrement, on en fait une autre version dans la même table. Donc on a les deux versions simultanément, et les ordres SQL choisissent ce qu'ils veulent. Cette seconde version est répliquée, pas de problème. C'est les VACUUM qui posent problème, puisqu'ils veulent supprimer les vieilles versions d'enregistrement, qui ne sont plus nécessaires sur le primaire. Le hot_standby_feedback permet justement aux standby de prévenir le maître des enregistrement dont ils ont encore besoin.
Marc.
Hors ligne
Pages : 1
