Répliques en lecture et retard de réplication : à quoi ressemblent les lectures obsolètes et comment les borner

Ce que c'est

Dans la réplication en flux de PostgreSQL, le primaire envoie les enregistrements du journal des écritures anticipées (write-ahead log) aux standbys, qui les rejouent ; un standby actif (hot standby) sert aussi les requêtes en lecture seule. La réplication est asynchrone par défaut : une validation (commit) revient avant qu'aucun standby n'ait reçu les données. La documentation citée décrit des niveaux de synchronous_commit qui font attendre la validation jusqu'à ce qu'un standby ait écrit, vidangé (flush) ou, avec remote_apply, rejoué la transaction de sorte qu'elle soit visible aux requêtes exécutées là-bas — ce que la documentation dit permettre, dans des cas simples, un équilibrage de charge avec cohérence causale ; les standbys concernés sont nommés dans synchronous_standby_names.

Le rejeu et les requêtes sont en concurrence. La documentation citée sur le hot standby explique que l'application du WAL peut entrer en conflit avec des requêtes en cours (par exemple lorsqu'une ligne dont une requête a besoin a été nettoyée sur le primaire) ; passé max_standby_streaming_delay, la requête en conflit est annulée, et hot_standby_feedback empêche le VACUUM du primaire de supprimer des lignes dont un standby a encore besoin, au prix d'un gonflement (bloat) sur le primaire. La supervision s'appuie sur pg_stat_replication côté primaire et sur les fonctions de position de rejeu citées, comme pg_last_wal_replay_lsn(), côté standby.

Pourquoi c'est important

Le bug typique : un utilisateur soumet un formulaire (écriture sur le primaire), la page suivante liste des éléments (lecture sur la réplique) et le nouvel élément est absent ; une nouvelle tentative le fait apparaître. Les tâches d'arrière-plan qui lisent sur une réplique agissent sur un état obsolète. Ce ne sont pas des cas limites rares, mais le comportement normal sous retard.

Comment l'appliquer

• Classer les lectures : les lectures qui suivent une écriture dans le même flux utilisateur doivent aller au primaire, ou y rester épinglées pendant une courte période après toute écriture de cette session ; les tableaux de bord et la recherche peuvent utiliser les répliques librement.
• Pour une garantie stricte de type « lire ses propres écritures », enregistrer la position de validation du primaire et ne laisser la lecture sur la réplique procéder que lorsque sa position de rejeu l'a atteinte.
• Donner aux répliques analytiques un délai de standby important pour que les requêtes longues ne soient pas annulées ; garder ce délai court sur les répliques qui servent des lectures sensibles à la latence.
• Alerter sur le retard, en octets et en secondes, ainsi que sur le nombre d'annulations de requêtes sur chaque standby.
• N'utiliser les modes synchrones que pour les standbys et les charges de travail où la latence de validation supplémentaire et le risque de blocage des validations lorsqu'un standby est indisponible sont acceptés.

Pièges

Un proxy qui route les instructions par type (tout SELECT vers une réplique) peut détourner du primaire les propres lectures d'une transaction, à moins qu'il ne suive cette transaction. Une réplique promue lors d'un basculement (failover) peut accuser un retard par rapport à l'ancien primaire, si bien que des validations récentes peuvent être perdues avec la réplication asynchrone. Le retard sous forte charge d'écriture croît précisément au moment où les lectures sont les plus lourdes.