Répliquer les données dans Lakebase

Ce guide vous montre comment répliquer des données d’une base de données Postgres externe vers Lakebase en utilisant la réplication logique. Lakebase agit en tant qu’abonné : il se connecte à votre base de données source, copie les données existantes et applique des modifications continues jusqu’à ce que vous effectuiez la bascule. Utilisez cela pour migrer une base de données depuis un autre fournisseur Postgres, comme Amazon Aurora PostgreSQL ou Amazon RDS pour PostgreSQL, ou d’un serveur Postgres autogéré vers Lakebase.

Conditions préalables

  • Une base de données source Postgres avec un point de terminaison public accessible par Lakebase.

  • Accès superutilisateur sur la base de données source, ou un compte administrateur sur un service Postgres géré. Définir wal_level, créer un rôle avec l’attribut REPLICATION et créer une publication nécessitent tous ce niveau d’accès.

  • Un projet Lakebase pour la base de données cible.

  • Un rôle Lakebase Postgres pour créer l’abonnement : un membre du databricks_superuser rôle, tel que le rôle du propriétaire du projet, ou un rôle à qui l’on accorde à la fois le pg_create_subscription rôle prédéfini et le CREATE privilège sur la base de données cible. Le pg_create_subscription rôle seul ne suffit pas. Sans CREATE sur la base de données, CREATE SUBSCRIPTION échoue avec permission denied for database. Pour attribuer databricks_superuser à un autre rôle, voir Créer des rôles Postgres ou Mettre à jour un rôle.

    GRANT pg_create_subscription TO <role_name>;
GRANT CREATE ON DATABASE <database_name> TO <role_name>;

La réplication logique est prise en charge dans Lakebase. Il n’y a pas d’étape par projet pour l’activer. En tant qu’abonné, Lakebase n’a besoin d’aucune modification de wal_level. Seul l’éditeur source en a besoin wal_level = logical.

Préparer la base de données source

Dans votre base de données source Postgres, réglez le journal d’écriture anticipée sur logical et confirmez qu’il y a une capacité de réplication. L’exemple suivant concerne Postgres autogéré. Votre fournisseur Postgres géré peut utiliser différents paramètres :

ALTER SYSTEM SET wal_level = logical;
ALTER SYSTEM SET max_wal_senders = 10;
ALTER SYSTEM SET max_replication_slots = 10;

Redémarrez la base de données source pour que la modification de wal_level prenne effet. Sur un service géré, utilisez le groupe de paramètres ou les drapeaux du fournisseur pour définir wal_level à logical. Par exemple, sur Amazon Aurora PostgreSQL, définissez rds.logical_replication sur 1 dans le groupe de paramètres du cluster de base de données et redémarrez le cluster. Sur Amazon RDS pour PostgreSQL, définissez le même paramètre dans le groupe de paramètres de la base de données et redémarrez l’instance.

Créez un rôle de réplication et accordez-lui un accès de lecture aux tables que vous répliquez :

CREATE ROLE replication_user WITH REPLICATION LOGIN PASSWORD '<password>';
GRANT USAGE ON SCHEMA public TO replication_user;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO replication_user;

Cette CREATE ROLE instruction fonctionne telle qu’elle est écrite sur un serveur Postgres autogéré. Certains fournisseurs Postgres gérés n’autorisent pas directement cet REPLICATION attribut et accordent plutôt un accès à la réplication via un rôle spécifique à chaque fournisseur. Si votre source fonctionne sur un service managé, suivez la documentation du fournisseur pour accorder au rôle l’accès de réplication, puis utilisez ce rôle à la place de replication_user dans les étapes suivantes. Par exemple, sur Amazon Aurora PostgreSQL et Amazon RDS for PostgreSQL, créez le rôle sans WITH REPLICATION puis exécutez GRANT rds_replication TO replication_user.

Créez une publication pour les tables que vous souhaitez répliquer. Chaque table doit avoir un PRIMARY KEY ou une identité de réplica définie. Voir Replica identity dans la documentation Postgres.

CREATE PUBLICATION my_publication FOR TABLE orders, customers;

Permettre à Lakebase d’atteindre la source

En tant qu’abonné, Lakebase établit une connexion sortante vers votre base de données source. Cette connexion sortante est régie par la politique réseau de votre compte, qui contrôle les destinations internet que les charges de travail serverless peuvent atteindre. Il n’est pas contrôlé par un paramètre de projet Lakebase ni par un rôle dans la base de données.

La nécessité d’effectuer un changement dépend de si votre compte applique une politique réseau :

  • Aucune politique réseau active : Lakebase peut atteindre tout éditeur disposant d’un point de terminaison public atteignable. Aucun changement n’est nécessaire.
  • Une politique réseau active : ajouter l’hôte de la base de données source aux destinations internet autorisées dans la politique réseau du compte. Consultez Gérer les stratégies réseau. Si l’hôte n’est pas autorisé, l’abonnement est refusé lors de sa création. Consultez la rubrique Résolution des problèmes.

Private Link n’est pas pris en charge pour la connexion de l’abonné. La base de données source doit être accessible via son point de terminaison public.

Créez les tables cibles

La réplication logique copie les données, pas le schéma. Créez les tables dans la base de données Lakebase cible avec les mêmes noms et colonnes que la source avant de commencer la réplication. Vous pouvez les créer manuellement, ou exporter le schéma depuis la source et le charger dans Lakebase. Voir Exporter uniquement le schéma.

Créez les tables cibles vides. La copie initiale de la table échoue en cas de clés dupliquées ou de violations de contraintes si une table cible contient déjà des lignes.

Créez l’abonnement

Connectez-vous à la base de données cible Lakebase avec un rôle pouvant créer des abonnements (voir Prérequis), puis créez un abonnement qui se connecte à l’éditeur source :

CREATE SUBSCRIPTION my_subscription
CONNECTION 'host=<source-host> port=5432 dbname=<source-db> user=replication_user password=<password> sslmode=verify-full sslrootcert=system'
PUBLICATION my_publication;

Créer l’abonnement lance un slot de réplication sur l’éditeur source, copie les lignes existantes, puis diffuse les changements en cours.

Warning

Le slot de réplication permet à la base de données source de conserver le journal d’écriture anticipée (WAL) jusqu’à ce que Lakebase confirme avoir reçu les modifications. Si l’abonnement cesse de consommer des modifications, par exemple parce qu’il est désactivé, déconnecté ou en échec, le WAL s’accumule sur la source sans limite. Sur une source de production, cela peut remplir le stockage de la source et provoquer une panne.

Pendant l’exécution de la réplication, surveillez la quantité de WAL que le slot conserve sur la source :

SELECT slot_name, active,
       pg_catalog.pg_size_pretty(pg_catalog.pg_wal_lsn_diff(pg_catalog.pg_current_wal_lsn(), restart_lsn)) AS retained_wal
FROM pg_catalog.pg_replication_slots;

Pour limiter le risque sur une source autogérée, définissez max_slot_wal_keep_size pour limiter la quantité de WAL qu’un slot peut conserver. Si un slot dépasse la limite, Postgres l’invalide et l’abonnement doit être recréé. Résiliez l’abonnement dès que vous aurez terminé la migration. Voir slots de réplication et stockage.

Note

Lorsque Lakebase sֹ’abonne, il se connecte à votre base de données source et lui envoie les informations d’identification du rôle de réplication. sslmode=verify-full avec sslrootcert=system chiffre la connexion et vérifie l’identité de la source, ce qui protège les informations d’identification relayées contre un intercepteur. Cela fonctionne lorsque votre source utilise une autorité de certification publiquement fiable. Le sslmode=require le plus faible chiffre mais ne vérifie pas la source. La vérification d’une source utilisant une autorité de certification privée n’est pas prise en charge.

Vérifier la réplication

Dans la base de données Lakebase cible, confirmez que les lignes existantes sont arrivées :

SELECT COUNT(*) FROM orders;

Insérez ou mettez à jour une ligne sur la source, puis interrogez à nouveau la cible. Le changement apparaît sur Lakebase en quelques secondes.

Surveillez et basculez

Suivez la copie initiale et la latence persistante :

SELECT subname, received_lsn, latest_end_lsn, last_msg_receipt_time
FROM pg_catalog.pg_stat_subscription;

Pour confirmer que la copie initiale est terminée, exécutez la requête d’état de synchronisation par table dans Surveiller la réplication sur l’abonné et attendez que chaque table lise Ready (fully live).

Lorsque la cible a rattrapé son retard, arrêtez les écritures sur la source, confirmez que la cible est pleinement à jour, puis basculez votre application vers les détails de connexion Lakebase.

La réplication logique ne copie pas les valeurs de séquence ni les compteurs d’identité. Avant de reprendre les écritures sur Lakebase, réinitialisez chaque séquence cible pour qu’elle corresponde aux données répliquées, sinon de nouvelles insertions dans SERIAL ou les colonnes d’identité peuvent générer des clés primaires dupliquées :

SELECT pg_catalog.setval(pg_catalog.pg_get_serial_sequence('orders', 'id'), (SELECT MAX(id) FROM orders));

Une fois que votre application fonctionne avec Lakebase, supprimez l’abonnement pour arrêter de répliquer depuis la source. Lorsque la source est accessible, la suppression de l’abonnement supprime également l’emplacement de réplication qui s’y trouve. Voir Supprimer un abonnement ou une publication.

Pour la surveillance et le nettoyage, voir Gérer et surveiller la réplication logique.

Étapes suivantes

  • Dernière mise à jour :