Réplication et PITR

Prérequis : cours 4.2 (sauvegardes DevOps) et précédent (WAL).

Pourquoi

Dump quotidien = RPO 24 h. Insuffisant ? La réplication (copie en continu) + PITR (retour à un instant précis) réduisent RPO à minutes et RTO à bascule. À mettre en place avant d'en avoir besoin.

Concepts

• WAL shipping / streaming : le journal d'écriture rejoué sur un standby en continu. Le standby peut servir les lectures (hot standby) et devenir primaire (failover).
• Synchrone vs asynchrone : synchrone = zéro perte (écriture attendue par le standby) mais latence ; asynchrone = rapide, quelques secondes perdables. Choisir selon le RPO, pas par défaut.
• PITR (Point-In-Time Recovery) : base de dimanche + WAL jusqu'à mardi 14h32 = état exact d'avant la boulette. Exige : base + archive WAL continue (archive_mode = on + archive_command testée !).
• Failover ≠ magique : bascule manuelle ou auto (Patroni, Stolon…), avec fencing (tuer l'ancien primaire !) sinon split-brain (deux primaires qui divergent = enfer).

Exemple : archive qui marche

archive_command = 'test ! -f /archives/%f && cp %p /archives/%f'
# Tester : forcer un switch (CHECKPOINT; SELECT pg_switch_wal();) et vérifier le fichier

Cas réel

DROP TABLE à 14h00, dump de 4h : sans PITR = 10 h de données perdues ; avec WAL archivées = restore à 13h59, 20 minutes d'interruption. L'archive_command jamais testée d'un concurrent : répertoire vide le jour J — d'où le test.

Pièges

• Standby jamais testé en failover : le jour J il ne remonte pas (conf, version, retard appliqué).
• Synchrone sans standby sain : chaque écriture attend un mort = base figée. Monitorer le retard (pg_stat_replication).
• Split-brain : deux primaires = deux vérités. Fencing obligatoire en failover auto.

À retenir

Streaming + WAL archivées testées, synchrone selon RPO, failover testé avec fencing.