Vous n'êtes pas identifié(e).
Pages : 1
Bonjour ,
Je cherche une requête , si c'est possible, qui envoie le même résultat que "show pool_nodes;" ou une requête qui envoie le Gap de la replication Standby
postgres=> show pool_nodes;
node_id | hostname | port | status | lb_weight | role | select_cnt | load_balance_node | replication_delay
---------+----------+------+--------+-----------+---------+------------+-------------------+-------------------
0 | osspc19 | 5432 | down | 0.500000 | standby | 0 | false | 0
1 | osspc20 | 5432 | up | 0.500000 | primary | 0 | true | 0
Merci d'avance
Djam
Hors ligne
bonjour,
Comme ça rapidement je dirais :
select * from pg_stat_replication;
Sinon vous pouvez aussi envoyer simultanement les requêtes suivantes sur le master et sur le slave :
select pg_current_xlog_location(); (sur le master)
select pg_last_xlog_receive_location(); (sur le slave)
Cordialement,
Sébastien.
Hors ligne
Merci sébastien pour ta réponse :-), j'ai noté tes requetes qui me donnent pas mal d'infos sur la replication.
j'ai trouvé cette requête sur le net, je ne sais pas si il faut la lancer sur le master ou la standby! tu as une idée stp
[ réf https://www.enterprisedb.com/blog/monit … gresql-93]
ii. Calculating lags in Seconds. The following is SQL, which most people uses to find the lag in seconds:
SELECT CASE WHEN pg_last_xlog_receive_location() = pg_last_xlog_replay_location()
THEN 0
ELSE EXTRACT (EPOCH FROM now() - pg_last_xact_replay_timestamp())
END AS log_delay;
Hors ligne
ça marche sur les deux.
Dernière modification par ruizsebastien (28/02/2018 14:09:11)
Cordialement,
Sébastien.
Hors ligne
Cette requête n'a un intérêt que sur un standby. De plus, elle sert à mesurer la différence entre ce qui a été reçu et rejoué sur le standby. En gros, ça aide à savoir si tout ce qui a été reçu est réellement visible ou s'il reste des enregistrements à rejouer. Elle ne sert pas du tout à connaître le retard du standby avec le master.
Guillaume.
Hors ligne
Merci Guillaume pour tes explications, à tout hasard, tu n'as pas une requête qui permet de retourner le retard de la Standby par rapport à la primaire
Hors ligne
Le problème, c'est qu'il n'y a pas qu'une seule réponse à ça. Ça dépend de votre version de PostgreSQL, ça dépend aussi du retard dont vous parlez (données envoyées ? données enregistrées ? données rejouées ?). En fait, vous devez soustraire l'emplacement actuel des journaux de transactions (pg_current_wal_lsn()) avec la position reçue (sent_lsn), rejouée (replay_lsn), ou autre, à partir de la vue système pg_stat_replication.
Guillaume.
Hors ligne
OK, c'est noté.
notre version est 9.6
Hors ligne
Pages : 1
