Aller au contenu principal

Répliquer des données dans Lakebase

Ce guide vous explique comment répliquer des données d’une base de données Postgres externe vers Lakebase à l’aide de la réplication logique. Lakebase joue le rôle d’abonné : il établit une connexion sortante à votre base de données source, copie les données existantes et applique les modifications au fur et à mesure jusqu’à ce que vous basculiez. Utilisez cette méthode pour migrer une base de données depuis un autre fournisseur Postgres, tel qu’Amazon Aurora PostgreSQL ou Amazon RDS for PostgreSQL, ou depuis un serveur Postgres autogéré vers Lakebase.

Prérequis​

  • Une base de données Postgres source avec un endpoint public que Lakebase peut atteindre.
  • Accès superutilisateur sur la base de données source, ou le compte administrateur sur un service Postgres géré. La définition de wal_level, la création d’un rôle avec l’attribut REPLICATION et la création d’une publication nécessitent 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 : membre du rôle databricks_superuser ou rôle auquel le rôle prédéfini pg_create_subscription a été accordé. Consultez Créer des rôles Postgres.

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 ne nécessite pas de changement wal_level. Seul l'éditeur de la source nécessite wal_level = logical.

Préparer la base de données source​

Sur votre base de données Postgres source, définissez le journal de pré-écriture sur logical et confirmez que la capacité de réplication est suffisante. L'exemple suivant concerne Postgres auto-géré. Votre fournisseur Postgres géré peut utiliser des paramètres différents :

SQL
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 wal_level prenne effet. Sur un service géré, utilisez le groupe de parameter ou les indicateurs du fournisseur pour définir wal_level sur 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 parameter dans le groupe de parameter de la base de données et redémarrez l'instance.

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

SQL
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 instruction CREATE ROLE fonctionne telle qu’elle est écrite sur un serveur Postgres autogéré. Certains fournisseurs Postgres gérés n’autorisent pas directement l’attribut REPLICATION et accordent plutôt l’accès à la réplication via un rôle spécifique au fournisseur. Si votre source s’exécute sur un service géré, suivez la documentation du fournisseur pour donner au rôle l’accès à la 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éplique définie. Voir Identité de réplique dans la documentation Postgres.

SQL
CREATE PUBLICATION my_publication FOR TABLE orders, customers;

Autoriser Lakebase à atteindre la source​

En tant qu'abonné, Lakebase effectue un appel sortant 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 auxquelles les charges de travail serverless peuvent accéder. Il n'est pas contrôlé par un paramètre de projet Lakebase ou un rôle dans la base de données.

Le fait que vous deviez effectuer une modification dépend de si votre compte applique une politique de réseau :

  • Aucune politique réseau active : Lakebase peut joindre tout éditeur disposant d'un endpoint public accessible. Aucun changement n'est nécessaire.
  • Une politique réseau active : ajoutez l'hôte de la base de données source aux destinations Internet autorisées dans la politique réseau du compte. Voir Gérer les politiques réseau. Si l'hôte n'est pas autorisé, l'abonnement est rejeté lors de sa création. Voir Dépannage.

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

Créer les tables cible​

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 start la réplication. Vous pouvez les créer manuellement ou vider le schéma de la source et le charger dans Lakebase. Consultez N’exporter que le schéma.

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

Créer l'abonnement​

Connectez-vous à la base de données Lakebase cible en tant que rôle pouvant créer des abonnements (voir Conditions préalables), puis créez un abonnement se connectant au serveur de publication source :

SQL
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;

La création de l'abonnement start un emplacement de réplication sur l'éditeur source, copie les lignes existantes, puis Stream les modifications en cours.

attention

The replication slot makes the source database retain write-ahead log (WAL) until Lakebase confirms it has received the changes. If the subscription stops consuming changes, for example because it is disabled, disconnected, or failing, WAL accumulates on the source without limit. On a production source, this can fill the source's storage and cause an outage.

While replication runs, monitor how much WAL the slot retains on the source:

PostgreSQL
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;

To cap the risk on a self-managed source, set max_slot_wal_keep_size to limit how much WAL a slot can retain. If a slot exceeds the limit, Postgres invalidates it and the subscription must be re-created. Drop the subscription as soon as you finish the migration. See Replication slots and storage.

remarque

When Lakebase subscribes, it connects out to your source database and sends the replication role's credentials to it. sslmode=verify-full with sslrootcert=system encrypts the connection and verifies the source's identity, which protects the relayed credentials against a man-in-the-middle. It works when your source uses a publicly trusted certificate authority. The weaker sslmode=require encrypts but does not verify the source. Verifying a source that uses a private certificate authority is not supported.

Vérifier la réplication​

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

SQL
SELECT COUNT(*) FROM orders;

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

Surveiller et effectuer le basculement​

Suivez la copie initiale et le retard continu :

SQL
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 query de statut de synchronisation par table dans Surveiller la réplication sur l’abonné et attendez que chaque table indique Ready (fully live).

Lorsque la cible est à jour, arrêtez les écritures sur la source, vérifiez que la cible est totalement à jour et basculez votre application sur les détails de connexion Lakebase.

La réplication logique ne copie pas les valeurs de séquence ou les compteurs d'identité. Avant de reprendre les écritures sur Lakebase, Reset chaque séquence cible pour correspondre aux données répliquées, ou les nouvelles insertions dans SERIAL ou les colonnes d'identité peuvent générer des clés primaires en double :

SQL
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 la réplication depuis la source. Lorsque la source est accessible, la suppression de l’abonnement supprime également l’emplacement de réplication sur celle-ci. Consultez Supprimer un abonnement ou une publication.

Pour le monitoring et le nettoyage, voir Gérer et monitorer la réplication logique.

Étapes suivantes​