Comment vérifier le délai de réplication dans PostgreSQL?
J'aimerais mesurer le temps entre l'insertion de données dans la table maître et la table esclave à l'aide de la réplication en continu dans PostgreSQL 9.3 Pour cela, je crée la table test_time avec 2 champs id (serial), t (text). Après cela ajouté un déclencheur:
cur_time:=to_char(current_timestamp, 'HH12:MI:SS:MS:US');
update test_time set t=cur_time where id=new.id;
Mais le temps est le même dans les deux tableaux . Comment puis-je mesurer le temps de retard
Vous pouvez obtenir le délai en octets du côté du maître assez facilement en utilisant pg_xlog_location_diff pour comparer le pg_current_xlog_insert_location du maître avec le replay_location de l'entrée pg_stat_replication de ce moteur.
Cela ne fonctionne que lorsqu'il est exécuté sur le maître. Vous ne pouvez pas le faire à partir de la réplique, car celle-ci n’a aucune idée de l’avance du maître.
De plus, cela ne vous indiquera pas le décalage en secondes . Dans les versions PostgreSQL actuelles (au moins à partir de la version 9.4), aucun horodatage n'est associé à un enregistrement commit ou WAL. Il n’ya donc aucun moyen de savoir depuis combien de temps un LSN (position xlog) était.
Le seul moyen d'obtenir le décalage du réplica en quelques secondes sur une version actuelle de PostgreSQL consiste à faire en sorte qu'un processus externe valide périodiquement une update dans une table d'horodatage dédiée. Vous pouvez donc comparer current_timestamp sur le réplica à l'horodatage de l'entrée la plus récente de cette table visible sur le réplica pour voir jusqu'où se trouve le réplica. Cela crée un trafic WAL supplémentaire qui devra ensuite être conservé dans votre WAL archivé pour PITR (PgBarman ou autre), de sorte que vous devez équilibrer l'utilisation accrue des données avec la granularité de détection de décalage que vous recherchez.
PostgreSQL 9.5 peut ajouter des horodatages de validation qui vous permettront, espérons-le, de savoir depuis combien de temps une validation est survenue et par conséquent de combien de temps une réplique est derrière en quelques secondes.
Alf162 a mentionné une bonne solution dans les commentaires à la réponse de Craig Ringer; alors j'ajoute ceci pour clarifier.
PostgreSQL a une fonction administrative pg_last_xact_replay_timestamp () qui renvoie l’horodatage de la dernière transaction lue lors de la récupération. Il s'agit de l'heure à laquelle l'enregistrement WAL de validation ou d'abandon pour cette transaction a été généré sur le principal.
Ainsi, cette requête select now()-pg_last_xact_replay_timestamp() as replication_lag sur un esclave renverra une durée représentant la différence de temps entre l'horloge actuelle et l'horodatage du dernier enregistrement WAL appliqué à partir du flux de réplication.
Notez que si le maître ne reçoit pas de nouvelles mutations, il n’y aura pas d’enregistrements WAL à diffuser et le décalage calculé de cette façon augmentera sans pour autant indiquer un retard dans la réplication. Si le maître subit une mutation plus ou moins continue, il transmettra en continu des WAL et la requête ci-dessus constitue une approximation fine du délai de modification des modifications sur le maître sur l'esclave. La précision sera évidemment affectée par la précision de la synchronisation des horloges système sur les deux hôtes.
Si votre base de données a des écritures fréquentes, la requête ci-dessous est une approximation proche pour obtenir le décalage de l'esclave
select now() - pg_last_xact_replay_timestamp() AS replication_delay;
Vous trouverez ci-dessous une requête plus précise pour calculer le délai de réplication des bases de données avec très peu d'écritures. Si le maître n'envoie aucune écriture à l'esclave, alors pg_last_xact_replay_timestamp () peut être constant et donc ne pas déterminer avec précision le décalage de l'esclave à l'aide de la requête ci-dessus.
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;
version légèrement différente de la bonne réponse:
postgres=# SELECT
pg_last_xlog_receive_location() receive,
pg_last_xlog_replay_location() replay,
(
extract(Epoch FROM now()) -
extract(Epoch FROM pg_last_xact_replay_timestamp())
)::int lag;
receive | replay | lag
------------+------------+-------
1/AB861728 | 1/AB861728 | 2027
le décalage n'a d'importance que lorsque "recevez" n'est pas égal à "rejouer". exécuter la requête sur l'esclave
à partir de 10 version:
https://www.postgresql.org/docs/10/static/monitoring-stats.html#pg-stat-replication-view
write_lag _ intervalle Temps écoulé entre le vidage local du WAL récent et la réception de la notification que ce serveur de secours dispose de l'a écrit (mais pas encore rincé ni appliqué). Cela peut être utilisé pour jauge du délai que synchro_commit du niveau remote_write a occasionné lors de la validation si ce serveur a été configuré en tant que synchrone Etre prêt.
flush_lag _ intervalle Temps écoulé entre le vidage local du fichier WAL récent et la réception de la notification que ce serveur de secours dispose de écrit et vidé (mais pas encore appliqué). Cela peut être utilisé pour jauge du délai que synchro_commit de niveau remote_flush a occasionné lors de la validation si ce serveur a été configuré en tant que synchrone Etre prêt.
replay_lag _ intervalle Temps écoulé entre le vidage local du fichier WAL récent et la réception de la notification que ce serveur de secours dispose de écrit, rincé et appliqué. Ceci peut être utilisé pour évaluer le délai ce niveau synchronous_commit remote_apply engagé lors de la validation si ce serveur a été configuré en mode veille synchrone.
(formatage le mien)
Hélas, les nouvelles colonnes semblent ne convenir qu’à la réplication synchrone (sinon, le maître ne saurait pas connaître le décalage exact), ainsi le délai de réplication asynchrone chack semble rester now()-pg_last_xact_replay_timestamp()...
sur master, vous pouvez faire select * from pg_stat_replication;
cela vous donnera:
| sent_lsn | write_lsn | flush_lsn | replay_lsn
-+-------------+-------------+-------------+-------------
| 8D/2DA48000 | 8D/2DA48000 | 8D/2DA48000 | 89/56A0D500
ceux-ci peuvent vous dire où se trouvent vos offsets ... comme vous pouvez le voir dans cet exemple, la lecture sur esclave est derrière.