Was ist Change Data Capture, und wie unterscheidet sich logbasiertes CDC vom Pollen einer Timestamp-Spalte?

Change Data Capture streamt Änderungen auf Zeilenebene aus einer Quelldatenbank. Logbasiertes CDC liest das Transaction Log direkt, erfasst also Inserts, Updates und Hard Deletes in Commit-Reihenfolge und belastet die Quelle kaum. Eine updated_at-Spalte zu pollen ist einfacher, verpasst aber Hard Deletes, verpasst Zwischenzustände zwischen zwei Polls, hängt davon ab, dass die Anwendung die Spalte pflegt, und kann Zeilen durch Uhr- oder Transaktionsgrenzen übersehen.

Bei CDC geht es darum, Änderungen auf Zeilenebene zu bekommen, statt ganze Tabellen neu zu lesen. Logbasiertes CDC, etwa mit Debezium auf dem Postgres Write Ahead Log oder dem MySQL Binlog, gibt dir jedes Insert, Update und Delete in Commit-Reihenfolge und legt fast keine Query-Last auf die Primary. Eine updated_at-Spalte zu pollen ist viel einfacher aufzusetzen und für sich langsam ändernde Referenzdaten völlig in Ordnung, hat aber echte Löcher. Hard Deletes sieht es überhaupt nicht, Zeilen bleiben also stromabwärts stillschweigend für immer bestehen. Es verpasst Zwischenzustände, wenn sich eine Zeile zwischen zwei Polls zweimal ändert, und es hängt davon ab, dass jeder Writer daran denkt, die Spalte zu setzen, was ein Altjob in unserem Bestand nie getan hat. Logbasiertes CDC hat seine eigenen Betriebskosten. Du brauchst einen Replication Slot, und wenn dein Consumer stockt, wird das Log nicht freigegeben und die Quelldisk läuft voll, was ein wirklich gefährlicher Fehlerfall ist. Ich überwache Slot Lag daher als First-Class-Alert neben dem Pipeline Lag.