Maîtrise de la Réplication PostgreSQL : Types et Configuration Expliqués

La réplication PostgreSQL maintient un second serveur suffisamment proche du primaire pour survivre à une panne matérielle, déplacer le trafic de lecture ou effectuer une migration contrôlée. Si votre base de données est une dépendance de production, vous devez savoir quel modèle de réplication PostgreSQL correspond à votre tolérance au risque avant qu'un nœud ne tombe en panne.

PostgreSQL vous offre deux choix courants : la réplication en continu et la réplication logique. La réplication en continu copie le WAL au niveau du cluster physique. La réplication logique envoie les modifications au niveau des lignes de tables sélectionnées via des publications et des abonnements.

Pourquoi la Réplication PostgreSQL est Importante

La réplication aide à résoudre quatre problèmes opérationnels courants :

Haute disponibilité : Si le primaire tombe en panne, vous pouvez promouvoir un serveur de secours et pointer les applications vers lui.
Reprise après sinistre : Un serveur de secours dans un autre emplacement peut vous protéger contre une panne au niveau du site.
Mise à l'échelle des lectures : Les requêtes en lecture seule peuvent être exécutées sur des serveurs de secours actifs au lieu du primaire en écriture.
Support de migration : La réplication logique peut aider à déplacer des tables sélectionnées entre différentes versions de PostgreSQL ou différentes structures de base de données.

La réplication ne remplace pas la sauvegarde. Un bug, une mauvaise migration ou un DELETE accidentel peuvent se répliquer rapidement. Maintenez des sauvegardes testées et une récupération à un instant précis en parallèle de la réplication.

Réplication en Continu (Réplication Physique)

La réplication en continu est la forme de réplication la plus courante et fondamentale dans PostgreSQL. Elle fonctionne en envoyant les enregistrements du journal de transactions (WAL) du serveur primaire à un ou plusieurs réplicas. Ces enregistrements WAL représentent chaque modification apportée à la base de données. Les réplicas appliquent ensuite ces enregistrements WAL à leurs propres fichiers de données, garantissant ainsi leur cohérence avec le primaire.

Réplication Synchrone vs Asynchrone

La réplication synchrone oblige le primaire à attendre un ou plusieurs serveurs de secours synchrones avant de signaler une validation au client. Le niveau de sécurité exact dépend de synchronous_commit ; par exemple, attendre que le WAL soit écrit est différent de l'attente de sa relecture. Vous obtenez une protection plus forte contre la perte de validations reconnues, mais chaque validation dépend désormais de la latence du réplica et du réseau.

La réplication asynchrone permet au primaire de valider localement et d'envoyer le WAL aux réplicas par la suite. C'est plus rapide pour les écritures, mais une panne du primaire peut entraîner la perte de transactions récentes qui n'avaient pas encore atteint un serveur de secours.

Configuration de la Réplication en Continu (Exemple Asynchrone)

La configuration de la réplication en continu implique la configuration des serveurs primaire et réplica. Voici un guide simplifié :

1. Configurer le Serveur Primaire (`postgresql.conf` et `pg_hba.conf`)

Sur le serveur primaire, vous devez activer l'archivage WAL et les connexions de réplication.

Modifications de postgresql.conf :
```
wal_level = replica  # ou logical pour la réplication logique
max_wal_senders = 5  # Nombre de connexions de réplication simultanées
wal_keep_size = 512MB # Ou wal_keep_segments pour les versions plus anciennes
# Pour la réplication synchrone, ajoutez :
# synchronous_standby_names = 'replica1,replica2'
# Ou pour un nom/priorité de serveur spécifique :
# synchronous_standby_names = '1 (replica1), 2 (replica2)'
archive_mode = on
archive_command = 'test ! -f /path/to/wal_archive/%f && cp %p /path/to/wal_archive/%f'
```
- wal_level : Doit être au moins replica pour la réplication en continu.
- max_wal_senders : Spécifie combien de serveurs de secours peuvent se connecter simultanément.
- wal_keep_size : Empêche la suppression des fichiers WAL avant que les réplicas puissent les récupérer (une alternative plus simple à archive_command pour les configurations de base, mais l'archivage est recommandé pour la robustesse).
- archive_mode et archive_command : Utiles pour la récupération à un instant précis (PITR) et pour les réplicas qui ont besoin d'anciens WAL après avoir pris du retard. En production, utilisez une cible d'archivage réelle ou un outil de sauvegarde au lieu d'une commande de copie locale.

Modifications de pg_hba.conf :

Autorisez le réplica à se connecter pour la réplication. Remplacez replica_ip_address par l'adresse IP réelle de votre réplica.

# TYPE  DATABASE        USER            ADDRESS                 METHOD
host    replication     replication_user  replica_ip_address/32   md5

Vous devrez également créer un utilisateur de réplication :

-- Sur le serveur primaire :
CREATE ROLE replication_user WITH REPLICATION LOGIN PASSWORD 'your_password';

Après avoir modifié ces fichiers, rechargez la configuration PostgreSQL :

pg_ctl reload
# Ou redémarrez PostgreSQL si nécessaire

2. Préparer le Serveur Réplica

Avant de démarrer le réplica, il doit avoir un répertoire de données qui est une copie du répertoire de données du primaire à un instant précis. Le moyen le plus simple est d'utiliser pg_basebackup.

Arrêtez PostgreSQL sur le réplica (s'il est en cours d'exécution).
Effectuez une sauvegarde de base :
```
# Assurez-vous que PGDATA est vide ou supprimé d'abord
pg_basebackup -h primary_host_ip -p 5432 -U replication_user -D /var/lib/postgresql/data/ -Fp -Xs -P -R
```
- -h, -p, -U : Spécifient les détails de connexion au serveur primaire.
- -D : Le répertoire de données pour le réplica.
- -Fp : Le format est simple.
- -Xs : Diffuse le WAL pendant la sauvegarde.
- -P : Affiche la progression.
- -R : Écrit les paramètres de connexion du serveur de secours et crée standby.signal pour PostgreSQL 12 et versions ultérieures.
- Le mot de passe de replication_user vous sera demandé.

3. Configurer le Serveur Réplica

Modifications de postgresql.conf (pour PG12+) :
```
hot_standby = on # Permet les requêtes en lecture seule sur le réplica
primary_conninfo = 'host=primary_host_ip port=5432 user=replication_user password=your_password'
```
- hot_standby : Active les requêtes en lecture seule sur le serveur de secours.
- primary_conninfo : Chaîne de connexion au serveur primaire.
Versions PostgreSQL plus anciennes :

PostgreSQL 12 a supprimé recovery.conf. Si vous maintenez un serveur plus ancien, créez recovery.conf dans le répertoire de données du réplica :
```
standby_mode = 'on'
primary_conninfo = 'host=primary_host_ip port=5432 user=replication_user password=your_password'
# Si vous utilisez la récupération par archivage au lieu du streaming, spécifiez restore_command
# restore_command = 'cp /path/to/wal_archive/%f %p'
# recovery_target_timeline = 'latest'
```
Sur PostgreSQL 12 et versions ultérieures, le mode veille est contrôlé par standby.signal, et primary_conninfo réside généralement dans postgresql.auto.conf lorsqu'il est créé par pg_basebackup -R.

4. Démarrer le Serveur Réplica

Démarrez le service PostgreSQL sur le réplica. Il se connectera au primaire, recevra les enregistrements WAL et commencera à se synchroniser. Vous pouvez vérifier les journaux pour confirmation.

Astuce : Pour une haute disponibilité robuste, envisagez d'utiliser des outils comme Patroni ou repmgr, qui automatisent le basculement et la gestion.

Réplication Logique

La réplication logique est une forme de réplication plus flexible et granulaire introduite dans PostgreSQL 10. Au lieu de répliquer des blocs entiers de données ou des enregistrements WAL, elle réplique les modifications de données en fonction de leur signification logique (par exemple, les instructions INSERT, UPDATE, DELETE) au niveau des lignes. Ceci est réalisé en décodant les enregistrements WAL en un flux de modifications logiques.

Fonctionnalités Clés et Cas d'Utilisation :

Réplication sélective : Vous pouvez choisir les tables à répliquer. Les versions récentes de PostgreSQL prennent également en charge les listes de colonnes dans les publications, mais vérifiez la version de votre serveur avant de vous fier à cette fonctionnalité.
Réplication inter-versions : La réplication logique peut répliquer des données entre différentes versions majeures de PostgreSQL.
Contrôle du schéma : La réplication logique ne réplique pas automatiquement le DDL. Créez des tables correspondantes et appliquez les migrations de schéma sur l'abonné.
Transformation de données : Bien qu'elle ne soit pas intégrée, la réplication logique fournit une base pour des processus ETL (Extract, Transform, Load) plus complexes.
Réplication d'un Primaire vers un Réplica qui n'est pas un clone complet : La base de données cible n'a pas besoin d'être une copie physique complète de la source.

Comment ça Marche :

Éditeur : La base de données source (primaire) où les modifications de données se produisent. Elle nécessite wal_level = logical. Les modifications sont décodées du WAL en un flux logique.
Publication : Un ensemble nommé de tables sur l'éditeur dont les modifications seront répliquées.
Abonné : La base de données cible (réplica) qui reçoit les modifications.
Abonnement : Une connexion sur l'abonné qui se connecte à l'éditeur et applique les modifications d'une publication spécifique.

Configuration de la Réplication Logique

1. Configurer l'Éditeur (Serveur Primaire)

Modifications de postgresql.conf :

wal_level = logical
max_replication_slots = 10 # Pour les slots de réplication logique
max_wal_senders = 10     # Doit être au moins égal à max_replication_slots

Créer une Publication :

-- Sur la base de données de l'éditeur :
CREATE PUBLICATION my_publication FOR TABLE 
    table1, 
    table2 
    WITH (publish = 'insert,update,delete');

-- Ou pour toutes les tables :
-- CREATE PUBLICATION all_tables_pub FOR ALL TABLES;

Rechargez la configuration sur l'éditeur.

2. Configurer l'Abonné (Serveur Réplica)

Assurez-vous que les tables cibles existent : La base de données de l'abonné doit avoir les tables cibles avec le même schéma que l'éditeur. Vous pouvez les créer manuellement ou utiliser pg_dump pour extraire le schéma.
Créer un Abonnement :
```
-- Sur la base de données de l'abonné :
CREATE SUBSCRIPTION my_subscription
    CONNECTION 'host=publisher_host_ip port=5432 user=replication_user password=your_password dbname=publisher_db'
    PUBLICATION my_publication;
```
replication_user doit disposer des autorisations appropriées sur l'éditeur.

PostgreSQL créera automatiquement un slot de réplication sur l'éditeur et commencera à appliquer les modifications. Vous pouvez surveiller l'état de l'abonnement à l'aide de pg_stat_subscription sur l'abonné.

Astuce : La réplication logique utilise l'infrastructure de décodage logique intégrée de PostgreSQL. Elle ne nécessite pas d'extension séparée pour les publications et abonnements de base.

Choisir la Méthode de Réplication Appropriée

Réplication en Continu : Idéale pour la haute disponibilité et la reprise après sinistre, où vous avez besoin d'une copie exacte, octet par octet, du primaire. Sa configuration est plus simple pour la réplication complète de la base de données et offre la meilleure évolutivité en lecture pour les réplicas en lecture seule.
Réplication Logique : La mieux adaptée pour la distribution sélective des données, les migrations, les mises à niveau inter-versions, ou lorsque vous devez répliquer uniquement un sous-ensemble de données. Elle permet des scénarios plus complexes comme la réplication vers différents schémas ou la réalisation de transformations de données.

À Retenir

Utilisez la réplication en continu lorsque vous avez besoin d'un serveur de secours complet pour le basculement, la reprise après sinistre ou le trafic en lecture seule. Utilisez la réplication logique lorsque vous avez besoin de tables sélectionnées, d'une migration inter-versions ou d'un déplacement contrôlé de données entre différentes bases de données.

Avant de faire confiance à l'une ou l'autre configuration, effectuez un exercice de basculement, vérifiez la gestion des connexions des applications, surveillez le retard de réplication et assurez-vous que les sauvegardes se restaurent toujours correctement. La réplication maintient un autre serveur à jour ; elle ne remplace pas les tests opérationnels.