Réplication et répliques en lecture

La réplication maintient une ou plusieurs copies de la base : haute disponibilité et répartition des lectures.

Réplication physique (streaming)#

Le primaire envoie son journal WAL à des standbys qui rejouent les changements : copie exacte, en lecture seule.

-- Sur une réplique : est-elle en retard ?
SELECT now() - pg_last_xact_replay_timestamp() AS retard;

• Asynchrone (défaut) : un COMMIT n'attend pas les répliques ; rapide, mais une bascule peut perdre les dernières transactions.
• Synchrone : le COMMIT attend la confirmation d'au moins une réplique ; durabilité renforcée, latence plus élevée.

Réplication logique#

Publie des tables (ou des changements de lignes) vers un autre serveur, éventuellement d'une autre version : migrations sans coupure, alimentation d'un entrepôt de données, dissémination vers d'autres systèmes.

-- Sur la source
CREATE PUBLICATION ma_pub FOR TABLE commandes, clients;
-- Sur la destination
CREATE SUBSCRIPTION ma_sub CONNECTION 'host=source dbname=app user=repl' PUBLICATION ma_pub;

Le piège de la lecture sur réplique#

Piège : une réplique asynchrone a du retard (replication lag). Un utilisateur qui crée une commande puis recharge sa page peut ne pas la voir si la lecture part vers une réplique. Routez vers le primaire les lectures qui suivent immédiatement une écriture (« read your writes »), et réservez les répliques aux rapports et aux lectures tolérantes.

Haute disponibilité#

La bascule automatique (failover) est assurée par des outils comme Patroni ou par les services managés (RDS Multi-AZ, Cloud SQL HA…). Testez-la régulièrement : une bascule jamais exercée est une bascule qui échoue le jour J.