• Attention au vocabulaire !
• Identifier le besoin
• Keep It Simple...

• Connaître les principaux outils de réplication
• Identifier les différences entre les solutions proposées
• Choisir le système le mieux adapté à votre besoin

• Cluster
• Réplication
  • synchrone / asynchrone
  • symétrique / asymétrique
  • diffusion des modifications

• Dans la terminologie PostgreSQL
  • groupe autonome de bases de données
  • i.e. une instance
• Dans la terminologie haute-disponibilité et/ou réplication
  • groupe de serveurs

• Asymétrique
  • écritures sur un serveur maître unique
  • lectures sur le maître et/ou les esclaves
• Asynchrone
  • les écritures sur les esclaves sont différées
  • perte de données possible en cas de crash du maître
• Quelques exemples
  • streaming replication, Slony, Londiste, Bucardo

• Symétrique
  • écritures sur les différents maîtres
  • besoin d'un gestionnaire de conflits
  • lectures sur les différents maîtres
• Asynchrone
  • les écritures sur les esclaves sont différées
  • perte de données possible en cas de crash du maître

• Asymétrique
  • écritures sur un serveur maître unique
  • lectures sur le maître et/ou les esclaves
• Synchrone
  • les écritures sur les esclaves sont immédiates
  • le client sait si sa commande a réussi sur l'esclave

• Symétrique
  • écritures sur les différents maîtres
  • besoin d'un gestionnaire de conflits
  • lectures sur les différents maîtres
• Synchrone
  • les écritures sur les esclaves sont immédiates
  • le client sait si sa commande a réussi sur l'esclave
  • risque important de lenteur

• 4 types de récupération des informations de réplication
• Par requêtes
  • diffusion de la requête
• Par triggers
  • diffusion des données résultant de l'opération
• Par journaux, physique
  • diffusion des blocs disques modifiés
• Par journaux, logique
  • extraction et diffusion des données résultant de l'opération depuis les journaux

• Réplication
  • asymétrique
  • asynchrone ou synchrone
• Esclaves
  • non disponibles (Warm Standby)
  • disponibles en lecture seule (Hot Standby, à partir de la 9.0)
  • cascade possible à partir de la 9.2
  • retard possible à partir de la 9.4

• But
  • envoyer les journaux de transactions à un esclave
• Première solution disponible (dès 2006)
• Gros inconvénient
  • il est possible de perdre un journal de transactions entier

• But
  • avoir un retard moins important sur le maître
• Rejouer les enregistrements de transactions du maître par paquets
  • paquets plus petits qu'un journal de transactions
• Solution idéalement couplée au Hot Standby

• Intégré à PostgreSQL depuis 2006
• Serveur de secours en cas de panne
• L'esclave est identique au maitre
  • à quelques transactions près

• Évolution du Warm Standby apparue en 9.0
• Basé sur le même mécanisme
• Le serveur secondaire est ouvert aux connexions
  • et aux requêtes en lecture seule
• Différentes configurations
  • asynchrone ou synchrone
  • application immédiate ou retardée

• Réplique les changements
  • sur une seule base de données
  • d’un ensemble de tables défini
• Uniquement INSERT / UPDATE / DELETE
  • pas les DDL, ni les TRUNCATE

• Création d'une publication sur un serveur
• Souscription d'un autre serveur à cette publication

• Non répliqués :
  • Schémas
  • Séquences
  • Large objects
• Pas de publication des tables parentes du partitionnement
• Ne convient pas comme fail-over

• Un très large choix !
• Quel solution choisir ?
  • pgPool
  • Slony / Bucardo / Londiste
  • Postgres-XC

• Projet libre (BSD)
• Synchrone / Symétrique
• Réplication des requêtes SQL
• Site web

• Réplication basée sur les requêtes
• Capable de récupérer certaines fonctions non déterministes

• pgPool est à l'origine un pooler de connexions
• Configuration propre
• Plus ou moins transparent pour les applications
• Réplication de toutes les requêtes
  • y compris le DDL

• pgPool est un SPOF
  • SPOF => Single Point Of Failure
• Réplication basée sur la réplication des requêtes SQL
  • obligation de passer par pgpool
• Prise en main et fonctionnement complexe
• Authentification en mode réplication
  • pas de md5
  • pas de méthodes externes (LDAP, Radius, etc.)
• Effet « couteau suisse »

• Base de données de secours
• Répartition de charge en lecture

• Projet libre (BSD)
• Asynchrone / Asymétrique
• Diffusion des résultats (triggers)
• Site web

• Réplication de tables sélectionnées
• Procédures de bascule
  • switchover / switchback
  • failover / failback

• Réplication basée sur des triggers
• Démons externes, écrits en C
• Le maître est un provider
• Les esclaves sont des subscribers

• Choix des tables à répliquer
• Indépendance des versions de PostgreSQL
• Technique de propagation des DDL
• Robustesse

• Le réseau doit être fiable : peu de lag, pas ou peu de coupures
• Supervision délicate
• Modifications de schémas complexes

• Clusters en cascade
• Réplications complexes
• Infocentre (many to one)
• Bases spécialisées (recherche plein texte, traitements lourds, etc)

• Projet libre (BSD)
• Asynchrone / Asymétrique
• Réplication des résultats
• Site web

• Réplication de tables sélectionnées
• Procédures de bascule
  • switchover / switchback
  • failover / failback

• Réplication basée sur des triggers
• Démons externes, écrits en Python
• Utilise un autre outil provenant des Skytools : PgQ
• 1 maître / N esclaves

• PgQ est robuste, fiable et flexible
• Pas de groupes de réplication, mais des tables appartenant à différentes queues

• Technique de propagation des DDL basique
• Très peu de fonctionnalités.

• Clusters en cascade
• Réplications complexes
• Infocentre (many to one)
• Bases spécialisées (recherche plein texte, traitements lourds, etc)

• Projet libre (BSD)
• Asynchrone / Symétrique ...
• ... ou Asynchrone / Asymétrique
• Réplication des résultats (dits deltas)
• Site web

• Réplication maître-maitre ou maître-esclave
• Répartition des écritures
• Failover manuel
• Plusieurs méthodes de résolution des conflits

• Réplication basée sur des triggers
• Démons externes, écrits en Perl
• Maître / maître (1 seul couple)
  • ou maître / esclave(s)

• Basé sur un(des) set(s) de réplication et non sur un(des) schéma(s)
• Simplicité d'utilisation
• Résolution standard des conflits

• Aucune technique de propagation des DDL
  • (en cours de développement)
• Limité à deux nœuds en mode multi-maîtres
• Le réseau doit être fiable
  • peu de retard, pas ou peu de coupures
• Sous Linux/Unix uniquement
• Un seul développeur sur le projet
• Manque de fiabilité de l'​outil

• Cluster maître/maître simple
• Base de données de secours

• Projet libre (Licence PostgreSQL)
• Réplication multi-maîtres synchrone
• Réplication des résultats
• Ancien site web
• Projet renommé en postgres-x2

• Réplication multi-maîtres synchrone
• Distribution des données entre serveurs
  • partitionnement horizontal
• Répartition de charge
• Haute-disponibilité

• Global Transaction Manager
  • gestion des XID et conflits
• Coordinator
  • Catalogue / Répartiteur
• Datanode
  • Stockage

• Installation relativement aisée et bien documentée
• Intégration au cœur de PostgreSQL
• Ajout d'ordres DDL spécifiques

• Version dérivée de PostgreSQL
  • basée sur la version 9.3
• Chaque ordre SQL doit être porté
• Fonctionnalités manquantes
  • triggers, SQL/MED, savepoints, SSI
  • contraintes globales, détection globale des deadlock

• Très grandes bases transactionnelles sous forte charge
• Bases spécialisées
• Peu de cas d'utilisation connus en production

• Postgres-R
• PGCluster
• replicator
• cybercluster

• RAID
• DRBD
• SAN Mirroring
• À prendre évidemment en compte...

• Obligatoire
• Fiabilité d'un serveur.
• RAID 1 ou RAID 10
• Lectures plus rapides
  • dépend du nombre de disques impliqués

• Simple / synchrone / Bien documenté
• Lent / Esclave inaccessible / Linux uniquement

• Comparable à DRBD
• Solution intégrée
• Manque de transparence

Points essentiels :

• bien définir son besoin
• identifier tous les SPOF
• superviser son cluster
• tester régulièrement les procédures de Failover ( Loi de Murphy...)

• Doc officielle : Chapitre 25
• Hors série « Haute-disponibilité avec PostgreSQL » dans GNU/Linux France Magazine
• Article de blog « Hot Standby : Un exemple concret »

N'hésitez pas, c'est le moment !

• Différentes solutions de réplication
  • par requêtes, par trigger, par journaux de transactions
• Jusqu'à la 9.0
  • installation d'un outil supplémentaire
• Mais à partir de la 9.0
  • réplication interne

• Mise en place du maître
• Mise en place d'un esclave
  • Warm Standby
  • Hot Standby
• Mise en place de la Streaming Replication
  • asynchrone
  • synchrone
  • en cascade

• Les journaux de transactions contiennent toutes les modifications
  • utilisation du contenu des journaux
• L'esclave doit posséder une image des fichiers à un instant t
• La réplication modifiera les fichiers
  • d'après le contenu des journaux suivants

• 8.2 : Réplication par journaux (Log Shipping), Warm Standby
• 9.0 : Réplication en flux (Streaming Replication), Hot Standby
• 9.1 : Réplication synchrone
• 9.2 : Réplication en cascade
• 9.3 : Changement de maître en streaming
• 9.4 : Slots de réplication, délai de réplication, décodage logique
• 9.5 : pg_rewind, archivage depuis un esclave
• 9.6 : Rejeu synchrone
• 10 : Réplication synchrone sur base d'un quorum, slots de réplication temporaires

• Système de rejeu éprouvé
• Mise en place simple
• Pas d'arrêt ou de blocage des utilisateurs
• Réplique tout

• Réplication de l'instance complète
• Impossible de changer d'architecture
• Blocage complet de l'esclave en dehors des lectures
• Même version majeure de PostgreSQL pour tous les serveurs

• 3 étapes :
  • création du répertoire d'archivage
  • configuration de PostgreSQL
  • rechargement de la configuration

• Choix du répertoire d'archivage
• Répertoire local
  • ne pas oublier les droits et le propriétaire
• Répertoire distant
  • montage NFS
  • protocoles SSH, Samba, rsync

• Configuration (postgresql.conf)
  • wal_level = replica (ou logical)
  • archive_mode = on (ou always)
  • archive_command = '... une commande ...'
  • archive_timeout (optionnel)
• Ne pas oublier de forcer l'écriture de l'archive sur disque

• Configuration (postgresql.conf) - suite
  • wal_keep_segments
  • vacuum_defer_cleanup_age
  • max_replication_slots ( >= 9.4 )

• Rechargement de la configuration
  • par redémarrage de PostgreSQL (si wal_level ou archive_mode changés)
  • par envoi d'un signal à PostgreSQL

• Seul test possible : l'archivage
• Générer de l'activité
• pg_switch_wal
• Vérifier le bon archivage
  • en regardant le contenu du répertoire d'archivage
  • et/ou en consultant pg_stat_archiver
• Sans archivage, vérifiez les logs

• Identique à la restauration d'une sauvegarde PITR
• Jusqu'en 8.4
  • configuration spécifique du restore_command
  • pas de cp, scp, lftp, rsync, etc.
  • à remplacer par un outil externe spécifique
• Depuis 9.0
  • fonctionnalité intégrée au moteur

• Un deuxième serveur prêt à prendre la main

• Un deuxième serveur inutilisable
  • tant qu'on ne le sort pas de la restauration
• Et tous les inconvénients de la sauvegarde de fichiers

• Disponible depuis la 9.0
  • Mode recommandé
• configuration
  • restore_command = cp ou scp ou lftp ou ...
  • standby_mode = on
  • trigger_file = '/chemin/vers/fichier'

• Pré-requis : archivage des journaux de transactions
• Copie des données
• Soit manuel
• Soit avec un outil
  • pg_basebackup ( >= 9.1 )

• Configuration (recovery.conf)
  • automatisable avec pg_basebackup
• À partir de la 9.0
  • restore_command avec rsync
  • standby_mode = on

• Démarrer PostgreSQL

• Avec le Warm Standby, l'esclave n'est pas disponible
  • y compris pour des requêtes en lecture seule
• Hot Standby = esclave en lecture seule
• Activé par défaut en version 10

• Un deuxième serveur en lecture seule

• Aucune modification possible
  • données comme structure
  • y compris tables temporaires
• Et tous les inconvénients de la sauvegarde de fichiers

• Configuration du postgresql.conf
  • wal_level = replica
• Redémarrage de PostgreSQL

• Configuration du postgresql.conf
  • hot_standby = on
• Rechargement de la configuration

• Ne pas faire fichier par fichier
  • mais en flux
• Un processus du maître discute avec un processus de l'esclave
  • d'où un lag moins important
• Asynchrone ou synchrone (9.1)
• En cascade (9.2)

• Un lag de réplication beaucoup moins important
• Donc moins de perte en cas de bascule
• Aucune perte dans le cas du synchrone

• Si asynchrone
  • perte de données possibles pour ce qui n'a pas été envoyé à l'esclave
• Si synchrone
  • lenteurs à prévoir

• Configurer postgresql.conf
  • max_wal_senders = X
  • wal_sender_timeout = 60s

• Configurer pg_hba.conf
• L'esclave doit pouvoir se connecter au maître
• Pseudo-base replication
• Recharger la configuration

• Configuration du recovery.conf
  • standby_mode
  • primary_conninfo
  • trigger_file
  • archive_cleanup_command
• Configuration de postgresql.conf
  • wal_receiver_timeout
• Redémarrage de PostgreSQL

• Par défaut asynchrone
• À partir de la 9.1
  • synchrone possible
  • paramètre synchronous_standby_names
• À partir de la 9.6
  • plusieurs synchrones simultanés possibles
• À partir de la 10
  • synchrones basé sur un quorum
• Changement du statut avec synchronous_commit
  • on, off depuis toujours
  • local depuis la 9.1
  • remote_write depuis la 9.2
  • remote_apply depuis la 9.6

• Avant la 9.2
  • informations de réplication disponibles à partir du maître
  • donc beaucoup de travail sur le maître
  • et beaucoup de bande passante réseau
• À partir de la 9.2
  • un esclave peut fournir les informations de réplication
  • permet de décharger le maître de ce travail
  • permet de diminuer la bande passante du maître

• Système de réplication fiable
• Simple à maîtriser et à configurer
• Forte dynamique de développement

N'hésitez pas, c'est le moment !

• Bascule par promotion d'un serveur standby
• Procédure de reconnexion au nouveau serveur principal
• Automatisation
• Points à superviser

• Pré-requis et configuration
• Bascules
  • programmées (switch over)
  • d'urgence (fail over)
• Retour à l'état stable (fail back)
• Automatisation de ces opérations
• Supervision

• Configuration du système
• Configuration de PostgreSQL
• Stockage des journaux de transactions archivés

• Choisir un matériel de puissance équivalente
  • paramétrage mémoire et disque de PostgreSQL unique
  • perte de capacité en mode dégradé
• Points de défaillance possibles
  • baies, alimentation électrique, onduleur, routeurs, switchs...
• Avoir une ou plusieurs adresses IP dédiées au service pour éviter la reconfiguration des applications après bascule

• Unifier la configuration entre les nœuds :
  • matériel identique <=> paramètres mémoire et disque identiques
  • configurer les paramètres relatifs à la réplication sur tous les nœuds
  • créer un fichier modèle pour recovery.conf sur le principal
• S'assurer que pg_hba.conf ne bloque pas les clients en cas de bascule
• Propager les modifications de la configuration

• Plusieurs politiques d'archivages possibles
• Le serveur principal doit toujours archiver les journaux de transactions :
  • un archivage en panne peut provoquer un arrêt de service
  • la reprise sur panne nécessite des opérations pouvant retarder le retour à l'activité
• Chaque standby doit « nettoyer » les archives lui étant destinées
• Un standby indisponible doit être rapidement exclu de l'archivage s'il bloque celui-ci

• Bascule du service en écriture
• Cas de bascule :
  • perte du serveur principal
  • perte d'un serveur standby asynchrone
  • perte d'un serveur standby synchrone

• Promotion du serveur de standby :
  • paramètre trigger_file dans recovery.conf
  • méthode préférée : action promote de pg_ctl
• Déconnexion de la streaming replication (bascule programmée)
• Rejeu des dernières transactions en attente d'application
• Choix d'une nouvelle timeline du journal de transaction
• Ouverture aux écritures

• Promotion d'un serveur standby défini par :
  • option trigger_file dans recovery.conf
  • méthode préférée : action promote de pg_ctl
• Reconnexion des applications :
  • déplacer l'adresse IP du service
  • ou changer la configuration des applications
• Reconnexion des standby restants au nouveau principal par reconstruction

• Sortie de la ferme de standby en lecture seule
  • ne plus archiver les journaux de transactions sur ce serveur
  • reconfigurer les applications pour ne plus utiliser ce serveur
  • suppression du slot de réplication en cas de trop longue indisponibilité
• Ajouter un nouveau serveur de remplacement ?
• Reconnexion du standby une fois disponible
  • selon la disponibilité des journaux archivés

• Passage automatique sur un autre serveur standby synchrone en attente
• Ajout d'un nouveau standby synchrone de remplacement
• Cas d'un standby synchrone unique
  • les opérations en écriture sur le principal sont bloquées
  • passer synchronous_commit à local
  • recharger la configuration du serveur principal
  • annuler les transactions synchrones

• Si un standby a été promu avant la version 9.3 :
  • reconstruire les esclaves à partir d'une sauvegarde des fichiers du nouveau serveur principal
  • procédure la plus sûre pour tout serveur à connecter en standby
• À partir de la 9.3 : synchronisation automatique une fois la connexion rétablie
  • reconstruction obligatoire si l'esclave était plus avancé que le serveur promu

• Si un standby a été momentanément indisponible, reconnexion directe possible si
  • les journaux de transactions nécessaires sont encore présents sur l'instance principale
  • les journaux de transactions nécessaires sont présents en archives
  • dans les autres cas, reconstruction nécessaire

• Tâches à automatiser avec des scripts
• Outils disponibles
  • pacemaker
  • pgpool
  • repmgr
  • monit

• Base backup
  • démarrage et arrêt de la sauvegarde des fichiers
  • utilisation de rsync
  • prise en compte des tablespaces
• Configuration de recovery.conf
  • partir d'un fichier modèle

• L'objectif est de minimiser le temps d'interruption du service en cas d'avarie
• Un peu de vocabulaire :
  • SPOF : Single Point Of Failure
  • Redondance : pour éviter les SPOF
  • Ressources : éléments gérés par un cluster
  • Fencing et STONITH (Shoot The Other Node In The Head) : protection contre les corruptions

• Solution de Haute-Disponibilité généraliste
• Se base sur Corosync, un service de messagerie inter-nœuds
• Permet de surveiller la disponibilité des machines
• Gère le quorum et les cas STONITH
• Gère les ressources d'un cluster et leur interdépendance

• Postgres Automatic Failover
• Ressource Agent pour Pacemaker et Corosync permettant de :
  • Détecter un incident
  • Relancer l'instance maître
  • Basculer sur un autre nœud en cas d'échec de relance
  • Élire le meilleur esclave (avec le retard le plus faible)
  • Basculer les rôles au sein du cluster en maître et esclave
• Avec les fonctionnalités offertes par Pacemaker & Corosync :
  • Surveillance de la disponibilité du service
  • Quorum & Fencing
  • Gestion des ressources du cluster

• Outil spécialisé PostgreSQL
• Propose l'exécution de scripts de bascule automatique en cas de problème
  • health check
  • failover automatique

• Outil spécialisé PostgreSQL
• Gère automatiquement la bascule en cas de problème
  • Health check
  • Failover et switchover automatiques

• Outil de supervision des processus
• Détection de défaillance et exécution d'action selon le contexte

• Archivage
• État du serveur
• Gestion des conflits
• Retard de réplication

• Processus d'archivage
  • indique la réussite ou l'échec du dernier archivage
  • vue pg_stat_archiver (9.4)
• Fichiers en attente d'archivage
  • pg_wal/archive_status/*.ready
• Traces applicatives
  • message en cas d'échec de la commande d'archivage

• Une fonction de statut
  • pg_is_in_recovery()
  • pour connaître l'état d'un serveur
• Une vue système
  • pg_stat_replication
  • pour connaître le type de réplication, le retard des esclaves
  • en 9.3, fonction pg_wal_lsn_diff
  • en 10, write_lag, flush_lag, replay_lag

• Une requête en lecture pose des verrous
• Un conflit peut avoir lieu entre ces verrous et l'application des changements pour la réplication
• Quatre paramètres
  • max_standby_archive_delay
  • max_standby_streaming_delay
  • vacuum_defer_cleanup_age
  • hot_standby_feedback

• Deux fonctions de contrôle
  • pg_wal_replay_pause() pour mettre en pause
  • pg_wal_replay_resume() pour reprendre
• Une fonction de statut
  • pg_is_wal_replay_paused()

• Procédures de bascule et retour à l'état stable simples et documentées
• Possibilité d'automatiser les bascules avec des solutions de clustering tierces

N'hésitez pas, c'est le moment !

• Principes
• Mise en place
• Supervision

• Principes
• Mise en place
• Administration
• Supervision
• Limitations

• Connaître les avantages et limites de la réplication logique
• Savoir mettre en place la réplication logique
• Savoir administrer et superviser une solution de réplication logique

• Réplication physique
  • depuis la 9.0
  • beaucoup de possibilités
  • mais des limitations
• Réplication logique
  • permet de résoudre certaines des limitations de la réplication physique
  • auparavant uniquement disponible via des solutions externes
  • en interne depuis la version 10

• Réplication physique
  • instance complète
  • par bloc
  • asymétrique
  • asynchrone/synchrone
• Réplication logique
  • par table
  • par type d'opération
  • asymétrique (une origine des modifications)
  • asynchrone/synchrone

• Pas de réplication partielle
• Pas de réplication entre différentes versions majeures
• Pas de réplication entre différentes architectures
• Pas de réplication multidirectionnelle

• Serveur origine
  • et serveurs de destination
• Publication
  • et abonnement

• Paramètre wal_level
• Processus wal sender
  • mais pas de wal receiver
  • un logical replication worker à la place
• Asynchrone / synchrone

• Par table
  • publication pour toutes les tables
  • publications pour des tables spécifiques
• Par opération
  • insert, update, delete

• Pas de réplication des requêtes DDL
  • et donc pas de TRUNCATE
• Pas de réplication des valeurs des séquences
• Pas de réplication des LO (table système)
• Contraintes d'unicité obligatoires pour les UPDATE/DELETE

• Cas simple
  • 2 serveurs
  • une seule origine
  • un seul destinataire
  • une seule publication
• Plusieurs étapes
  • configuration du serveur origine
  • configuration du serveur destination
  • création d'une publication
  • ajout d'une souscription

• Création et configuration de l'utilisateur de réplication
  • et lui donner les droits de lecture des tables à répliquer
• Configuration du fichier postgresql.conf
  • wal_level = logical
• Configuration du fichier pg_hba.conf
  • autoriser une connexion de réplication du serveur destination

• Création de l'utilisateur de réplication
• Création, si nécessaire, des tables répliquées
  • pg_dump -h serveur_origine -s -t la_table la_base | psql la_base

• Ordre SQL

  CREATE PUBLICATION nom
    [ FOR TABLE [ ONLY ] nom_table [ * ] [, ...]
  | FOR ALL TABLES ]
    [ WITH ( parametre_publication [= valeur] [, ... ] ) ]

• parametre_publication étant seulement le paramètre publish
  • valeurs possibles : insert, update, delete
  • les trois par défaut

• Ordre SQL

  CREATE SUBSCRIPTION nom
  CONNECTION 'infos_connexion'
  PUBLICATION nom_publication [, ...]
  [ WITH ( parametre_souscription [= value] [, ... ] ) ]

• infos_connexion est la chaîne de connexion habituelle

• copy_data
  • copie initiale des données (activé par défaut)
• create_slot
  • création du slot de réplication (activé par défaut)
• enabled
  • activation immédiate de la souscription (activé par défaut)
• slot_name
  • nom du slot (par défaut, le nom de la souscription)
• synchronous_commit
  • pour surcharger la valeur du paramètre synchronous_commit
• connect
  • connexion immédiate (activé par défaut)

• Réplication complète d'une base
• Réplication partielle d'une base
• Réplication croisée

• 4 serveurs
  • s1, 192.168.10.1 : origine de toutes les réplications, et destination de la réplication croisée
  • s2, 192.168.10.2 : destination de la réplication complète
  • s3, 192.168.10.3 : destination de la réplication partielle
  • s4, 192.168.10.4 : origine et destination de la réplication croisée
• Schéma
  • 2 tables ordinaires
  • 1 table partitionnée, avec trois partitions

• Configuration du serveur origine
• Configuration du serveur destination
• Création de la publication
• Ajout de la souscription

• Création et configuration de l'utilisateur de réplication

  CREATE ROLE logrepli LOGIN REPLICATION;
  GRANT SELECT ON ALL TABLES IN SCHEMA public TO logrepli;

• Fichier postgresql.conf

  wal_level = logical

• Fichier pg_hba.conf

  host replication logrepli 192.168.10.0/24 trust

• Redémarrer le serveur origine
• Attention, dans la vraie vie, ne pas utiliser trust
  • et utiliser le fichier .pgpass

• Création de l'utilisateur de réplication

  CREATE ROLE logrepli LOGIN REPLICATION;

• Création des tables répliquées (sans contenu)

  createdb -h s2 b1
  pg_dump -h s1 -s b1 | psql -h s2 b1

• Création d'une publication de toutes les tables de la base b1 sur le serveur origine s1

  CREATE PUBLICATION publi_complete
    FOR ALL TABLES;

• Souscrire sur s2 à la publication de s1

  CREATE SUBSCRIPTION subscr_complete
    CONNECTION 'host=192.168.10.1 user=logrepli dbname=b1'
    PUBLICATION publi_complete;

• Un slot de réplication est créé
• Les données initiales sont immédiatement transférées

• Insertion, modification, suppression sur les différentes tables de s1
• Vérifications sur s2
  • toutes doivent avoir les mêmes données entre s1 et s2

• Identique à la réplication complète, à une exception...

• Créer la publication partielle

  CREATE PUBLICATION publi_partielle
    FOR TABLE t1,t2;

• Souscrire sur s3 à cette nouvelle publication de s1

  CREATE SUBSCRIPTION subscr_partielle
    CONNECTION 'host=192.168.10.1 user=logrepli dbname=b1'
    PUBLICATION publi_partielle;

• Insertion, modification, suppression sur les différentes tables de s1
• Vérifications sur s3
  • seules t1 et t2 doivent avoir les mêmes données entre s1 et s3
  • t3 et ses partitions ne doivent pas changer sur s3

• On veut pouvoir écrire sur une table sur le serveur s1
  • et répliquer les écritures de cette table sur s4
• On veut aussi pouvoir écrire sur une (autre) table sur le serveur s4
  • et répliquer les écritures de cette table sur s1
• Pour rendre le système encore plus intéressant, on utilisera la table partitionnée

• Créer la publication partielle sur s1

  CREATE PUBLICATION publi_t3_1
    FOR TABLE t3_1;

• Souscrire sur s4 à cette nouvelle publication de s1

  CREATE SUBSCRIPTION subscr_t3_1
    CONNECTION 'host=192.168.10.1 user=logrepli dbname=b1'
    PUBLICATION publi_t3_1;

• s4 devient aussi un serveur origine
  • il doit en avoir la configuration

• Fichier postgresql.conf

  wal_level = logical

• Fichier pg_hba.conf

  host all logrepli 192.168.10.0/24 trust

• Redémarrer le serveur s4

• Créer la publication partielle sur s4

  CREATE PUBLICATION publi_t3_2
    FOR TABLE t3_2;

• Souscrire sur s1 à cette publication de s4

  CREATE SUBSCRIPTION subscr_t3_2
    CONNECTION 'host=192.168.10.4 user=logrepli dbname=b1'
    PUBLICATION publi_t3_2;

• Insertion, modification, suppression sur t3, pour la partition 1, du serveur s1
• Vérifications sur s4, les nouvelles données doivent être présentes
• Insertion, modification, suppression sur t3, pour la partition 2, du serveur s4
• Vérifications sur s1, les nouvelles données doivent être présentes

• Processus
• Fichiers
• Procédures
  • Empêcher les écritures sur un serveur destination
  • Que faire pour les DDL
  • Gérer les opérations de maintenance
  • Gérer les sauvegardes

• Serveur origine
  • wal sender
• Serveur destination
  • logical replication launcher
  • logical replication worker

• 2 répertoires importants
• pg_replslot
  • slots de réplication
  • 1 répertoire par slot
  • 1 fichier state dans le répertoire
• pg_logical
  • méta-données
  • snapshots

• Par défaut, toutes les écritures sont autorisées sur le serveur destination
  • y compris écrire dans une table répliquée avec un autre serveur comme origine
• Problème
  • serveurs non synchronisés
  • blocage de la réplication en cas de conflit sur la clé primaire
• Solution
  • révoquer le droit d'écriture sur le serveur destination
  • mais ne pas révoquer ce droit pour le rôle de réplication !

• Les opérations DDL ne sont pas répliquées
• De nouveaux objets ?
  • les déclarer sur tous les serveurs du cluster de réplication
  • tout du moins, ceux intéressés par ces objets
• Changement de définition des objets ?
  • à réaliser sur chaque serveur

• Publication complète
  • rafraîchir les souscriptions concernées
• Publication partielle
  • ajouter la nouvelle table dans les souscriptions concernées

• À faire séparément sur tous les serveurs
• VACUUM, ANALYZE, REINDEX

• pg_dumpall et pg_dump
  • sauvegardent publications et souscriptions
  • nouvelles options --no-publications et --no-subscriptions
• Sauvegarde PITR
  • sauvegardent publications et souscriptions

• Méta-données
• Statistiques
• Outils

• pg_publication
  • définition des publications
  • \dRp sous psql
• pg_publication_tables
  • tables ciblées par chaque publication
• pg_subscription
  • définition des souscriptions
  • \dRs sous psql

• pg_stat_replication
  • statut de réplication
• pg_stat_subscription
  • état des souscriptions
• pg_replication_origin_status
  • statut des origines de réplication

• check_pgactivity
  • replication_slots
• check_postgres
  • same_schema

• Pas de réplication des requêtes DDL
  • et donc pas de TRUNCATE
• Pas de réplication des valeurs des séquences
• Pas de réplication des LO (table système)
• Contraintes d'unicité obligatoires pour les UPDATE/DELETE

• Enfin une réplication logique
• Réplication complète ou partielle
  • par objet (table)
  • par opération (insert/update/delete)

N'hésitez pas, c'est le moment !