Réplication

Réplication en flux

La réplication intégrée à PostgreSQL, dite « Streaming Replication », se base sur les mécanismes de sauvegarde et de restauration, pour mettre en œuvre une ou plusieurs instances dites « standby » d’une instance principale de PostgreSQL. 

Les procédés de sauvegardes physiques intégrées s’appuient eux-mêmes sur les journaux de transactions, et logiquement, la réplication de données consiste à rejouer, en continu, sur les instances « standby » le contenu de ces journaux de transactions.

Les premières techniques de réplication consistaient à relire les journaux de transactions archivés dans le cadre du paramètre archive_command. Cette technique existe toujours, et peut être utilisée pour permettre une souplesse accrue de la topologie des nœuds PostgreSQL.

Avec les versions 9 de PostgreSQL est apparu le protocole de réplication intégré, qui permet à une instance de se connecter à une autre instance, pour lire en continu le contenu des journaux de transactions.

Cette technique de réplication peut être utilisée en cascade, c’est-à-dire que chacun des serveurs « standby » peut servir de source de réplication à un autre serveur « standby » limitant ainsi le poids des serveurs « standby » sur le serveur principal.

Réplication synchrone

Par défaut, la réplication intégrée est asynchrone, c’est à dire que la transaction dans le serveur « primary » est validée avant d’être répliquée. Il est possible de configurer la réplication en mode synchrone afin de répliquer les données avant de valider la transaction. Par défaut, les données sont répliquées, mais pas immédiatement visibles dans l’instance « standby ». À partir de la version 9.6 de PostgreSQL, il est possible de configurer la réplication pour qu’elle soit synchrone jusqu’à la visibilité des données dans l’instance « standby ».

Une instance « standby » doit être déclarée dans la directive synchronous_standby_names de l’instance « primary ». Cette directive peut contenir une liste de noms, séparés par des virgules, ou des combinaisons avec les opérateurs FIRST ou ANY, comme expliqué au chapitre Exploitation. Chaque instance « standby » s’identifie en utilisant le paramètre application_name de la chaîne de connexion primary_conninfo du fichier recovery.conf.

Une fois l’instance « standby » démarrée pour...

Réplication logique intégrée

À partir de la version 10 de PostgreSQL, il est possible de mettre en place une réplication logique sans outil supplémentaire, c’est-à-dire sans utiliser Slony ou Londiste. Cette fonctionnalité s’appuie sur les journaux de transactions enrichis et décodés par les fonctions de décodage logique de PostgreSQL. Dans le cas de la réplication logique, quelle que soit la technique, on parle de « provider » pour désigner l’instance qui fournit la donnée, et de « subscriber » pour l’instance la recevant.

Afin de permettre cette réplication, il est nécessaire de modifier la valeur de la directive de configuration wal_level à logical, au lieu de replica par défaut. Cette modification nécessite un redémarrage de l’instance.

Une fois cette modification appliquée, et le fichier pg_hba.conf adapté pour accepter les connexions, les ordres CREATE PUBLICATION et CREATE SUBSCRIPTION suivants permettent de mettre en place un jeu de tables à répliquer, puis de s’y abonner depuis une autre instance.

L’ordre suivant permet de créer la publication, dans l’instance où les données des tables sont modifiées :

CREATE PUBLICATION clients_repli FOR TABLE public.clients, 
public.factures, public.prestations...

Réplication logique avec Slony

L’outil Slony-I est un système de réplication logique asynchrone maître-esclave. Il permet de répliquer des données entre plusieurs serveurs PostgreSQL, sachant qu’un seul de ces serveurs sera le serveur maître et les autres, les serveurs esclaves. Ces serveurs esclaves peuvent être mis en cascade, mais la quantité de serveurs esclaves doit rester raisonnable, afin de ne pas avoir d’impact négatif sur les performances.

Le serveur maître est celui qui doit être utilisé par les applications pour toutes les modifications de données. Les serveurs esclaves reçoivent une copie de ces modifications de façon asynchrone. Cette réplication asynchrone implique que le serveur maître n’attend pas la validation des serveurs esclaves pour valider sa propre transaction à l’application cliente. La validation d’une transaction sur le serveur maître ne tient compte que de l’état du serveur maître, et pas de celui des serveurs esclaves.

La réplication peut s’effectuer sur un réseau local ou sur des réseaux étendus (WAN) ; ceci est dû au fait que Slony utilise des connexions TCP entre les serveurs.

Les différentes possibilités de Slony sont :

L’unité de réplication de Slony est la table. Dans un même groupe de serveurs, Slony-I copie les données d’une table en utilisant des déclencheurs placés sur ces tables à l’initialisation de Slony. Il est possible d’utiliser plusieurs tables, à condition que toutes les tables existent au sein de la même base de données.

De plus, chaque table doit avoir une clé primaire ; si le modèle de données ne définit pas de clé primaire...