Réplication logique

La réplication logique est une méthode de réplication des objets de données et de leurs modifications en fonction de l'identité de réplication des objets et de leurs modifications. La réplication logique utilise un modèle de publication et d'abonnement dans lequel un ou plusieurs abonnés s'abonnent à une ou plusieurs publications sur un nœud d'éditeur. Les abonnés extraient des données des publications auxquelles ils sont abonnés.

La réplication logique vous permet de contrôler avec précision à la fois la réplication et la sécurité des données. Vous pouvez utiliser la réplication logique dans les cas d'utilisation suivants :

• Réplication entre différentes versions majeures de PostgreSQL

• Réplication entre des instances PostgreSQL sur différentes plateformes (par exemple, Linux vers Windows)

Architecture

Les étapes du flux de travail suivantes montrent le fonctionnement d'une architecture de réplication logique :

1. Vous prenez un instantané des données de la base de données de l'éditeur et vous les copiez dans la base de données des abonnés.

2. Les modifications apportées aux bases de données de l'éditeur sont transmises à l'abonné en temps réel.

3. L'abonné applique les données dans le même ordre que l'éditeur afin de garantir la cohérence transactionnelle des publications dans le cadre d'un seul abonnement.

Une publication peut être définie sur une instance principale (éditeur). Une publication est un ensemble de modifications générées à partir d'une table ou d'un groupe de tables. Vous pouvez choisir des modifications en combinant les opérations INSERT, UPDATE, DELETE et TRUNCATE. Par défaut, toutes ces modifications sont répliquées dans la base de données des abonnés. Cela contraste avec la réplication physique, où les adresses de bloc exactes sont utilisées pour une byte-by-byte réplication.

Une table publiée doit avoir une REPLICA IDENTITY configurée pour répliquer les opérations UPDATE et DELETE afin que les lignes appropriées à mettre à jour ou à supprimer puissent être identifiées côté abonné. Dans la plupart des cas, l'identité de la réplique est déterminée par une clé primaire ou une clé unique. Si aucune clé primaire n'est présente et que vous ne pouvez pas en créer une, vous pouvez définir l'identité de la réplique surfull. Cela signifie que la ligne entière devient la clé. Nous vous recommandons de définir l'identité de la réplique full en dernier recours, car ce paramètre est inefficace.

Un abonnement est la partie aval de la réplication logique. Le nœud où un abonnement est défini est appelé abonné. Un abonnement définit la connexion à une autre base de données et à un ensemble de publications (une ou plusieurs) auxquels il souhaite s'abonner.

Paramètres de configuration

Les configurations suivantes sont requises pour les paramètres de l'éditeur :

• wal_levelRéglé surlogical.

• max_replication_slotsParamétré pour prendre en compte au moins le nombre d'abonnements devant être connectés et certains emplacements réservés pour la synchronisation des tables.

• Configurez max_wal_senders en fonction de votre capacité d'accueil max_replication_slots et de votre nombre de répliques physiques.

Les configurations suivantes sont requises pour les paramètres des abonnés :

• Configurez max_replication_slots pour prendre en charge le plus petit nombre d'abonnements que vous prévoyez d'ajouter à l'abonné et certains abonnements réservés pour la synchronisation des tables.

• max_logical_replication_workersParamétré pour prendre en compte au moins le nombre d'abonnements et certains travailleurs de réserve pour la synchronisation des tables.

• Réglez max_worker_processes au moins sur (max_logical_replication_workers+1).

Chaque abonnement reçoit les modifications via un emplacement de réplication.

Les étapes suivantes indiquent comment effectuer une réplication logique :

1. Créez un éditeur en utilisant la commande CREATE PUBLICATION pour un groupe de tables (qui feront partie de la réplication) dans la base de données source.

2. Créez un abonné à l'aide de la commande CREATE SUBSCRIPTION, puis fournissez les détails de la publication lorsque vous créez l'abonné.

3. Le chargement de données initial commence automatiquement de la base de données source vers la base de données cible.

4. Les données de modification capturées par les emplacements de réplication sont répliquées dans la base de données cible.

5. Utilisez pg_stat_replication (une table de catalogue) pour vérifier l'état de la réplication. Utilisez pg_stat_replication_slots pour vérifier le slot de réplication.

Pour plus d'informations, consultez le billet Using logical replication to replicate managed Amazon RDS for PostgreSQL and Amazon Aurora to self-managed PostgreSQL sur le blog de base de données AWS.

Limites

Nous vous recommandons de prendre en compte les limites suivantes de la méthode de réplication logique avant de commencer votre migration :

• La réplication logique présente actuellement le plus grand nombre de restrictions et de lacunes fonctionnelles.

• La réplication logique ne permet pas de répliquer le langage de définition des données (DDL), les séquences et les opérations sur des objets volumineux. Une action de troncation (qui s'applique à une table avec une clé étrangère) doit inclure les tables associées dans le même abonnement.

Pour plus d'informations sur les limites de la réplication logique, reportez-vous à la section 31.6. Restrictions dans la documentation de PostgreSQL.