Kafka Connect (3/4) — Slot lag & monitoring Postgres

1Les 3 LSN du calcul de lag

Le lag implique 3 positions. Deux viennent du slot, la troisième est globale à l'instance.

Ordre garanti : confirmed_flush_lsn ≤ restart_lsn ≤ pg_current_wal_lsn().

lag_bytes = pg_current_wal_lsn() - confirmed_flush_lsn

2Pourquoi un slot retient le WAL même pour des tables inactives

Point le plus piégeux : le WAL Postgres est global à toute l'instance, pas partitionné par table ni par publication. Toutes les écritures de toutes les tables de toutes les bases vont dans le même WAL.

flowchart TB
  T1["stock.stock\n(dans la publication)\n10 writes/jour"]
  T2["audit.log\n(PAS dans la publication)\n500 000 writes/jour"]
  T3["metrics.raw\n(PAS dans la publication)\n2 000 000 writes/jour"]

  WAL["pg_wal/ — UN SEUL WAL GLOBAL\nevents séquentiels par LSN"]

  T1 --> WAL
  T2 --> WAL
  T3 --> WAL

  WAL --> SLOT["Slot Debezium\n📍 confirmed_flush_lsn"]
  SLOT -->|"publie uniquement\nstock.stock"| KAFKA["Kafka"]

Si la publication ne capture que stock.stock (10 writes/jour) mais que le reste de la base écrit 50 GB de WAL/jour, Debezium ne confirme des LSN que quand il lit un event de stock.stock. Entre deux events, le slot retient obligatoirement les 50 GB des autres tables — Postgres ne peut pas recycler au-delà du dernier LSN confirmé.

3Les 4 modes de défaillance

Mode 1 — Debezium est mort

Le slot est active=false. confirmed_flush_lsn est gelé. Lag = croissance linéaire proportionnelle au débit d'écriture de la base. Diagnostic immédiat : active=false depuis > 5 min.

Mode 2 — Debezium sous-dimensionné

Debezium tourne mais lit plus lentement que Postgres n'écrit. active=true, lag qui grossit en permanence. Diagnostic : tendance croissante sur courbe de lag.

Mode 3 — Tables capturées inactives (cas le plus piégeux)

Debezium tourne correctement, mais les tables de la publication sont peu actives par rapport au volume d'écriture global de l'instance. Debezium ne confirme que lorsqu'il traite un event de la publication — entre deux events, tout le WAL des autres tables est retenu. C'est le seul cas où le heartbeat aide.

Mode 4 — Slot orphelin (cas le plus grave)

Quelqu'un a détruit le cluster Connect sans drop le slot. Slot active=false, éternel. Personne ne le voit jusqu'à ce que le disque explose. Aucun monitoring applicatif ne l'attrape — seulement le monitoring SQL du lag.

4Le heartbeat en détail

heartbeat.action.query exécute un UPDATE dans une table capturée toutes les N secondes.

Mécanique :

1. UPDATE SQL → event dans le WAL à un LSN récent.
2. Debezium parcourt le WAL séquentiellement jusqu'à cet event (en skippant les tables non capturées).
3. Publie l'event heartbeat sur Kafka, reçoit ACK.
4. Confirme le LSN à Postgres → confirmed_flush_lsn avance au présent.
5. Les GB de WAL des autres tables, maintenant derrière le curseur, deviennent recyclables.

Pattern recommandé — table dédiée :

CREATE TABLE public.debezium_heartbeat (
  id INT PRIMARY KEY DEFAULT 1,
  ts TIMESTAMPTZ NOT NULL DEFAULT now(),
  CONSTRAINT single_row CHECK (id = 1)
);
INSERT INTO public.debezium_heartbeat VALUES (1, now());

-- Ajouter à la publication
ALTER PUBLICATION sie_debezium_pub ADD TABLE public.debezium_heartbeat;

"heartbeat.interval.ms": "10000",
"heartbeat.action.query": "UPDATE public.debezium_heartbeat SET ts = now() WHERE id = 1"

UPDATE en place, pas d'accumulation de lignes. Un seul heartbeat suffit même si la publication couvre plusieurs tables métier.

5Monitoring SQL et Grafana

SELECT
  slot_name,
  active,
  active_pid,
  confirmed_flush_lsn,
  pg_current_wal_lsn() AS current_lsn,
  pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn) AS lag_bytes,
  pg_size_pretty(
    pg_wal_lsn_diff(pg_current_wal_lsn(), confirmed_flush_lsn)
  ) AS lag_human
FROM pg_replication_slots
WHERE slot_type = 'logical';

Seuils d'alerte :

• active = false depuis 5 min → critique
• lag_human > 1 GB → warning
• lag_human > 10 GB → critique
• Dérivée positive continue sur 30 min sans redescendre → warning

Grafana via postgres_exporter :

• Métrique : pg_replication_slot_lag_bytes{slot_name="sie_debezium_slot"}
• Alerte : pg_replication_slot_active == 0 pendant 5 min → critique

Vendredi 18h15 — Cluster Connect crashe → confirmed_flush_lsn figé
Samedi 03h00  — 5 GB de lag → pas d'alerte (seuil absent ou trop haut)
Dimanche 09h00 — pg_wal/ à 95% du disque → alerte disque (trop tard)
Dimanche 10h00 — disque 100% → Postgres refuse toutes les écritures → outage total

6Procédures de reset

Cas 1 — Slot orphelin

-- Vérifier qu'il est inactif
SELECT slot_name, active, active_pid
FROM pg_replication_slots WHERE slot_name = 'sie_debezium_slot';

-- Drop (irréversible — Postgres recycle dès que possible)
SELECT pg_drop_replication_slot('sie_debezium_slot');

Cas 2 — Reset complet en prod

# 1. Arrêter le connector
PUT /connectors/sie-stock-source/stop

# 2. Supprimer les offsets côté Connect (connect-offsets)
DELETE /connectors/sie-stock-source/offsets

# 3. Supprimer le connector
DELETE /connectors/sie-stock-source

# 4. Drop le slot côté Postgres
# psql: SELECT pg_drop_replication_slot('sie_debezium_slot');

# 5. Recréer avec snapshot.mode=initial
POST /connectors

Cas 3 — Disque saturé d'urgence

-- Drop immédiat pour libérer le WAL
SELECT pg_drop_replication_slot('sie_debezium_slot');

Debezium au prochain démarrage ne trouvera plus son slot. Options : snapshot.mode=initial (resynchronisation complète, long) ou snapshot.mode=never (repart du LSN courant, trou dans l'historique). Choix selon tolérance à la perte d'events.

Sources

• Debezium — PostgreSQL Connector : Replication Slots — slot lag, heartbeat, procédures
• PostgreSQL — pg_replication_slots — colonnes et sémantique exacte
• Debezium Blog — Streaming from Postgres — lessons learned, slot lag, monitoring
• kafka-connect-2-debezium-cdc — WAL, LSN, slot, mécanique Debezium
• kafka-connect-1-fondamentaux — architecture Connect, connect-offsets
• kafka-connect-4-sink-smt-dlq — JDBC Sink & DLQ qui consomme les topics Debezium