La réplication logique est une méthode permettant de répliquer des données au niveau objet ainsi que les modifications apportées à ces objets, ceci basé sur leur identité de réplication (habituellement la clé primaire). L'utilisation du terme « réplication logique » est faite en opposition à la réplication physique qui elle, utilise l'adresse exacte des blocs couplée avec une réplication octet par octet. PostgreSQL supporte ces deux méthodes, référez-vous à l'article Chapitre 26, Haute disponibilité, répartition de charge et réplication. La réplication logique permet un contrôle fin des données au niveau de la réplication et de la sécurité.
La réplication logique utilise un système de publication/abonnement avec un ou plusieurs abonnés qui s'abonnent à une ou plusieurs publications d'un nœud particulier. Les abonnés récupèrent les données des publications auxquelles ils sont abonnés et peuvent éventuellement renvoyer ces informations pour permettre un système de réplication en cascade dans le cas de configurations plus complexes.
La réplication logique d'une table commence en générale en prenant un instantané des données sur la base publiée et le copiant vers la base abonnée. Une fois cette étape réalisée, les changements sur la base publiée sont envoyés à la base abonnée en temps réel. La base abonnée applique les modifications dans le même ordre qu'elles auront été réalisées de façon à ce que la cohérence transactionnelle soit garantie pour les publications d'un seul abonnement. Cette méthode de réplication porte parfois le nom de réplication transactionnelle.
Les cas typiques d'utilisation de la réplication logique peuvent être les suivants :
Envoyer immédiatement les changements réalisés sur une base de données, ou sur un sous-ensemble de ces données, de facon incrémentale à une base de données abonnée.
Déclencher des triggers pour des changements spécifiques lorsqu'ils apparaissent sur la base de données abonnée.
Réaliser la consolidation de plusieurs bases de données au sein d'une seule (par exemple pour répondre à des problématiques analytiques).
Réplication entre des versions majeures différentes de PostgreSQL.
Donner accès à des données répliquées à différents groupes d'utilisateurs.
Partager un sous-ensemble de données entre plusieurs bases de données.
Une base de données abonnée se comporte comme n'importe quelle autre base de données d'une instance PostgreSQL et peut être utilisée comme base de données de publication pour d'autres base de données en lui définissant ses propres publications. Lorsque la base abonnée est considérée comme une base en lecture seule par l'application, il ne va pas y avoir de problèmes de conflit. D'un autre côté, s'il y a des écritures provenant soit de l'application soit d'un autre abonnement sur le même ensemble de tables, des conflits peuvent survenir.
Une publication peut être définie sur n'importe quel serveur primaire de réplication physique. Le nœud sur laquelle la publication est définie est nommé éditeur . Une publication est un ensemble de modifications générées par une table ou un groupe de table et peut aussi être défini comme un ensemble de modifications ou un ensemble de réplication. Chaque publication existe au sein d'une seule base de données.
Les publications sont différenciées du schéma et n'ont pas d'impact sur la manière dont la base est accédée. Chaque table peut être ajoutée à différentes publications si besoin. Actuellement, les publications ne contiennent que les tables. Les objets doivent être ajoutés explicitement, sauf si la publication a été créée pour toutes les tables (ALL TABLES).
Les publications peuvent choisir de limiter les changements qu'elles produisent avec n'importe quelle combinaison de INSERT, UPDATE et DELETE, ceci d'une façon similaire à l'activation de triggers en fonction d'un certain type d'événement. Par défaut, tous les types d'opération sont répliqués.
Une table publiée doit avoir une « identité de réplication » configurée pour être capable de répliquer des opérations UPDATE et DELETE, pour que les lignes appropriées à modifier ou supprimer puissent être identifiées du côté de l'abonné. Par défaut, il s'agit de la clé primaire, si elle existe. Un autre index unique (avec quelques prérequis supplémentaires) peut aussi être configuré du côté de l'abonné. Si la table n'a pas de clé convenable, alors elle peut être configurée pour l'identité de réplica « full », ce qui signifie que la ligne entière devient la clé. Néanmoins, ceci est très inefficace et devrait seulement être utilisé si aucune autre solution n'est disponible. Si une identité de réplication est différente de « full » du côté du publieur, une identité de réplication comprenant les mêmes colonnes, ou moins de colonnes, peut aussi être configuré du côté de l'abonné. Voir ??? pour les détails sur la configuration de l'identité de réplication. Si une table sans identité de réplication est ajoutée à une publication qui réplique les opérations UPDATE ou DELETE, alors les opérations UPDATE ou DELETE suivantes causera une erreur sur le publieur. Les opérations INSERT peuvent se réaliser quelque soit l'identité de réplication.
Chaque publication peut avoir plusieurs abonnés.
Une publication est créée en utilisant la commande CREATE PUBLICATION(7) et peut ensuite être modifiée ou supprimée en utilisant la commande correspondante.
Les tables individuelles peuvent être ajoutées ou supprimées dynamiquement en utilisant ALTER PUBLICATION(7). Les opérations ADD TABLE et DROP TABLE sont toutes les deux transactionnelles ; de ce fait, une table va commencer ou arrêter de répliquer dans le bon instantané seulement une fois que la transaction a été validée.
Vue interne des journaux de
transaction
