<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kafka Connect on Frane Jelavic</title><link>https://franejelavic.github.io/tags/kafka-connect/</link><description>Recent content in Kafka Connect on Frane Jelavic</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Mon, 10 Aug 2026 17:00:00 +0200</lastBuildDate><atom:link href="https://franejelavic.github.io/tags/kafka-connect/index.xml" rel="self" type="application/rss+xml"/><item><title>Debezium and PostgreSQL in Production: Surviving Database Failover</title><link>https://franejelavic.github.io/writing/debezium-postgresql-production-lessons/</link><pubDate>Mon, 10 Aug 2026 17:00:00 +0200</pubDate><guid>https://franejelavic.github.io/writing/debezium-postgresql-production-lessons/</guid><description>&lt;p&gt;Getting Debezium to stream the first PostgreSQL change into Kafka is straightforward. Keeping that pipeline correct through database failover is where the interesting work begins.&lt;/p&gt;
&lt;p&gt;This post describes a failure mode we addressed while operating Debezium with PostgreSQL 16 and Patroni 3.3.1. After promoting a standby, Debezium needed a logical replication slot from which it could safely continue. Creating a new slot after promotion could start beyond Debezium’s last durable offset and introduce an event gap.
The central lesson was to treat PostgreSQL’s replication slot and Debezium’s Kafka Connect offset as parts of one distributed checkpoint.&lt;/p&gt;</description></item></channel></rss>