Gérer et surveiller la réplication logique

Cette page décrit comment surveiller la réplication logique dans Lakebase, comment la réplication interagit avec la mise à l’échelle jusqu’à zéro et les branches, et comment résoudre les problèmes courants. Pour la configuration, voir Répliquer les données dans Lakebase et Répliquer les données depuis Lakebase.

Surveiller la réplication

Tout rôle Postgres peut interroger les catalogues de réplication sur cette page, à deux exceptions près. La subconninfo colonne de pg_subscription peut contenir le mot de passe de connexion et est restreinte, donc sélectionnez des colonnes spécifiques au lieu d’utiliser SELECT *. Dans pg_stat_replication, la plupart des colonnes sont cachées à moins que votre rôle ne dispose de pg_read_all_stats, dont disposent les membres de databricks_superuser.

Pour un abonné, confirmez que l’abonnement existe et est activé :

SELECT subname, subenabled FROM pg_catalog.pg_subscription;

Sur l’éditeur, vérifiez que la publication existe :

SELECT pubname FROM pg_catalog.pg_publication;

Vérifiez le statut de synchronisation par table sur l’abonné. Lorsque chaque table affiche Ready (fully live), la copie initiale est terminée et la souscription est en cours de streaming :

SELECT
    srrelid::regclass AS table_name,
    CASE srsubstate
        WHEN 'i' THEN 'Initializing'
        WHEN 'd' THEN 'Data copying (in progress)'
        WHEN 's' THEN 'Synchronized (catching up)'
        WHEN 'r' THEN 'Ready (fully live)'
    END AS sync_status
FROM pg_catalog.pg_subscription_rel;

Vérifiez l’état de l’abonnement et le délai :

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

Comparez le nombre de lignes entre le serveur de publication et l’abonné pour confirmer qu’une table est synchronisée :

SELECT COUNT(*) FROM public.playing_with_lakebase;

Sur un publisher, listez les slots de réplication et jusqu’où chacun a progressé :

SELECT slot_name, slot_type, active, restart_lsn
FROM pg_catalog.pg_replication_slots;

Sur Lakebase, les résultats comprennent également les emplacements physiques internes wal_proposer_slot et wal_retention_slot. Lakebase gère ces slots, et ils ne font pas partie de la réplication logique.

Réplication logique et mise à l’échelle à zéro

Une ressource de calcul Lakebase avec un abonné actif ne peut pas être réduite à zéro, ce qui peut augmenter la consommation de calcul.

Vérifiez la présence d’abonnés actifs :

SELECT *
FROM pg_catalog.pg_stat_replication
WHERE application_name <> 'walproposer';

Slots de réplication et stockage

Un emplacement de réplication oblige l’éditeur à conserver le journal WAL (write-ahead log) jusqu’à ce que l’abonné confirme avoir reçu les modifications. Si l’abonné cesse de consommer les modifications, par exemple parce qu’il est désactivé, déconnecté, en échec ou en retard, le journal WAL s’accumule sur l’éditeur. C’est la cause la plus fréquente de problèmes graves de réplication logique :

  • L’éditeur peut manquer d’espace de stockage. Le WAL conservé augmente jusqu’à ce que le stockage de l’éditeur soit plein, ce qui peut empêcher la base de données d’accepter les écritures et provoquer une panne.
  • Retirer le slot ne libère pas immédiatement de la mémoire. Postgres ne retire le WAL conservé que lorsqu’il recycle les segments WAL à un point de contrôle ultérieur. Si l’éditeur a déjà épuisé son espace de stockage, ce recyclage risque de ne pas aboutir.
  • Le risque s’applique aussi aux éditeurs externes. Lorsque Lakebase s’abonne à une base de données externe, WAL s’accumule sur cette source externe si l’abonnement cesse de consommer des changements.

Surveiller le journal WAL conservé

Sur l’éditeur, vérifiez la quantité de données WAL conservées par chaque emplacement logique et si celui-ci est actif :

SELECT slot_name, active, wal_status,
       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
WHERE slot_type = 'logical';

Exécutez cette requête régulièrement pendant que la réplication est active. Examinez la situation lorsque retained_wal continue d’augmenter ou que active vaut false. Une valeur de wal_status égale à extended signifie que l’emplacement conserve davantage de données WAL que l’éditeur n’en conserve habituellement. Une valeur de wal_status égale à unreserved ou à lost signifie que l’emplacement a dépassé max_slot_wal_keep_size et perd, ou a déjà perdu, des données WAL nécessaires : l’abonnement doit donc être recréé.

Résoudre une accumulation de WAL

  1. Identifiez l’emplacement conservant les données WAL à l’aide de la requête présentée dans Surveiller le journal WAL conservé.

  2. Si l’abonné peut reprendre son fonctionnement, corrigez la cause (problème réseau, abonnement désactivé ou échec d’application, par exemple) pour qu’il rattrape son retard et que l’emplacement progresse.

  3. Si vous n’avez plus besoin de l’abonnement, supprimez-le sur l’abonné. Si l’abonné est inaccessible, supprimez directement l’emplacement sur l’éditeur. Un emplacement doit être inactif pour pouvoir être supprimé :

    SELECT pg_catalog.pg_drop_replication_slot('<slot_name>');

  4. Attendez que l’éditeur recycle les données WAL conservées. Sur un éditeur autogéré dont le stockage est presque saturé, ajoutez d’abord de l’espace pour permettre le recyclage.

Suppression automatique des emplacements inactifs sur Lakebase

Lorsque Lakebase est l’éditeur, il supprime automatiquement un emplacement de réplication inactif depuis environ 40 heures afin d’éviter une conservation indéfinie des données WAL. Un slot devient inactif lorsque son abonné cesse de consommer des changements et que le slot cesse d’avancer. Cela peut se produire lorsqu’un abonné est désactivé ou devient indisponible, ou lorsqu’un abonné est configuré avec un long délai de réplication.

Pour empêcher la suppression d’un emplacement, veillez à ce que son abonné reste connecté et continue de consommer les modifications. Si l’abonné utilise un délai ou une fréquence de réplication configurable, maintenez cette valeur sous 40 heures afin que l’emplacement continue de progresser. Si un emplacement est supprimé alors que vous en avez encore besoin, recréez l’abonnement sur l’abonné.

Les éditeurs externes ne suppriment pas automatiquement les emplacements inactifs. Sur un éditeur autogéré, définissez max_slot_wal_keep_size pour plafonner la quantité de données WAL qu’un emplacement peut conserver. Si un slot dépasse la limite, Postgres l’invalide et vous devez recréer l’abonnement.

La restauration d’une branche supprime les emplacements de réplication

Restaurer une branche supprime tous les slots de réplication sur cette branche. Recréez les publications et les abonnements après la restauration d’une branche.

Les branches enfants n’héritent pas des abonnements

Les abonnements définis sur une branche mère ne sont pas dupliqués sur ses branches enfants. Lakebase les supprime d’une branche enfant avant le début du calcul de cette branche, donc deux calculs ne répliquent pas le même abonnement. Cela s’applique lorsque vous créez, réinitialisez ou restaurez une branche enfant. Recréez l’abonnement sur la branche enfant si vous avez besoin de la réplication là-bas.

Supprimer une base de données d’abonnés laisse l’emplacement sur le serveur de publication

Lorsque vous supprimez une base de données qui comporte des abonnements via l’application Lakebase, la CLI Databricks ou l’API REST, Lakebase supprime d’abord ces abonnements, mais ne supprime pas leurs emplacements de réplication sur le serveur de publication. Chaque emplacement reste sur le serveur de publication et conserve le WAL, qui peut remplir le stockage du serveur de publication. Lors d’une migration, le serveur de publication est souvent votre base de données de production.

Une commande DROP DATABASE SQL se comporte comme dans Postgres standard : elle échoue avec database "<name>" is being used by logical replication subscription tant que la base de données a des abonnements.

Pour éviter de laisser un emplacement, retirez chaque abonnement avant de supprimer la base de données. Lorsque le serveur de publication est joignable, DROP SUBSCRIPTION supprime également l'emplacement sur le serveur de publication. Voir Supprimer un abonnement ou une publication.

Si vous avez déjà supprimé la base de données, supprimez l'emplacement restant sur le serveur de publication. Par défaut, l’emplacement d’un abonnement porte le même nom que l’abonnement. Si vous avez défini slot_name lorsque vous avez créé l’abonnement, utilisez ce nom à la place. Pour enregistrer les noms des slots avant de supprimer une base de données, exécutez SELECT subname, subslotname FROM pg_catalog.pg_subscription; dans cette base de données. Confirmez que l’emplacement existe et est inactif :

SELECT slot_name, database, plugin, active
FROM pg_catalog.pg_replication_slots
WHERE slot_type = 'logical' AND slot_name = '<slot_name>';

Ne supprimer que le slot qui appartenait à l’abonnement supprimé. D’autres emplacements inactifs peuvent appartenir à des abonnés ou à des outils de capture des données modifiées temporairement déconnectés, et leur suppression casse leur réplication. Retirez l’emplacement :

SELECT pg_catalog.pg_drop_replication_slot('<slot_name>');

Rôles de réplication

Un rôle dédié à la réplication doit avoir l’attribut REPLICATION. Les rôles créés dans l’application Lakebase, Azure Databricks CLI ou API REST possèdent cet attribut, qu’ils soient ou non membres de databricks_superuser. Les rôles créés avec SQL ne reçoivent pas automatiquement l’attribut REPLICATION. Pour en créer un avec SQL, incluez l’attribut, par exemple CREATE ROLE replication_user WITH LOGIN REPLICATION PASSWORD '<password>';. Pour l’ajouter à un rôle existant, exécutez ALTER ROLE <role_name> REPLICATION;. Les deux déclarations nécessitent un rôle qui possède les attributs CREATEROLE et REPLICATION, comme celui du propriétaire du projet.

Vérifiez les privilèges d’un rôle :

SELECT rolname, rolreplication
FROM pg_catalog.pg_roles
WHERE rolname = '<role_name>';

Plugins décodeurs

Lakebase prend en charge deux plugins de sortie de décodage logique :

  • pgoutput : le plugin de réplication logique intégré de Postgres, et celui par défaut. Utilisez-le pour la réplication standard de Postgres vers Postgres.
  • wal2json: produit les changements WAL sous forme de JSON, pour les systèmes qui consomment des données de changement en JSON.

Paramètres de l’éditeur

Sur Lakebase, max_wal_senders et max_replication_slots sont tous deux réglés sur 10:

max_wal_senders = 10
max_replication_slots = 10

max_wal_senders limite le nombre de processus expéditeurs WAL simultanés qui diffusent les modifications aux abonnés, tandis que max_replication_slots limite les emplacements de réplication permettant de suivre la progression des abonnés. Prévoyez un exemplaire de chaque élément par abonné. Pour demander différentes valeurs, contactez Databricks.

Créez un slot de réplication dédié

Certains services de données nécessitent un slot de réplication que vous créez à l’avance. Créez-en un avec la fonction Postgres standard, en nommant le plugin décodeur :

SELECT pg_catalog.pg_create_logical_replication_slot('my_replication_slot', 'pgoutput');

Supprimer un abonnement ou une publication

Supprimez un abonnement sur l’abonné lorsque vous n’en avez plus besoin. Lorsque le serveur de publication est accessible, la suppression de l’abonnement déconnecte du serveur de publication et supprime l’emplacement de réplication sur celui-ci. Les données répliquées restent dans la base de données de l’abonné.

DROP SUBSCRIPTION my_subscription;

Si le serveur de publication n’est pas accessible, DROP SUBSCRIPTION ne se termine pas car il ne peut pas se connecter pour supprimer l’emplacement distant. Dissociez d’abord l’emplacement, puis supprimez l’abonnement :

ALTER SUBSCRIPTION my_subscription DISABLE;
ALTER SUBSCRIPTION my_subscription SET (slot_name = NONE);
DROP SUBSCRIPTION my_subscription;

Dans ce cas, le slot de réplication reste sur le serveur de publication et continue de conserver le WAL. Supprimez-le sur l’éditeur pour libérer les données WAL :

SELECT pg_catalog.pg_drop_replication_slot('<slot_name>');

Supprimez une publication sur l’éditeur :

DROP PUBLICATION my_publication;

Troubleshooting

Symptôme Cause et résolution
L’abonnement ne parvient pas à se connecter. Vérifiez que l’éditeur est accessible et que la chaîne de connexion, le rôle et le mot de passe sont corrects. Lorsque Lakebase est le subscriber, confirmez que le point de terminaison de l’éditeur figure sur la liste d’autorisation de la stratégie réseau du compte. Voir Répliquer les données dans Lakebase.
Un abonnement à une autre base de données Lakebase reste bloqué et ne se connecte pas. La réplication entre bases de données Lakebase dans la même région n’est pas prise en charge. La source et la cible doivent se trouver dans des régions différentes. Consultez Limitations.
CREATE SUBSCRIPTION échoue avec restricted by Account Network Policies. Votre compte applique une stratégie réseau et l’hôte de l’éditeur ne figure pas parmi les destinations Internet autorisées. Ajouter l’hôte à la politique réseau du compte. Voir Répliquer les données dans Lakebase.
Le volume de stockage augmente sans être libéré. Un emplacement de réplication conserve des données WAL parce que son abonné ne consomme pas les modifications. Si cela n’est pas résolu, l’éditeur peut manquer de stockage. Vérifiez les données WAL conservées, puis reconnectez l’abonné ou supprimez l’emplacement. L’espace de stockage n’est libéré qu’une fois que l’éditeur a recyclé les données WAL. Voir Emplacements de réplication et stockage.
Les lignes n’arrivent pas sur l’abonné. Confirmez que les tables cibles existent avec des noms et colonnes correspondants, et que la publication inclut les tables que vous attendez.

Étapes suivantes

  • Dernière mise à jour :