Snapshot-then-Stream („Snapshot, dann Stream") ist das typische Startverfahren von Change Data Capture-Konnektoren: Zuerst wird eine konsistente Kopie des vorhandenen Datenbestands erstellt, danach werden die laufenden Änderungen als Ereignisstrom nachgeliefert.
Warum zwei Phasen?
Ein CDC-Werkzeug wie Debezium kennt zu Beginn nur den aktuellen Zustand der Quelltabelle. Um die Zieldatenbank vollständig zu befüllen, muss es zunächst den gesamten Bestand lesen — das ist der Snapshot. Gleichzeitig muss es den Zeitpunkt dieses Snapshots festhalten, damit anschließend genau die Änderungen nachgereicht werden, die während der Kopie entstanden sind. Die Kombination aus vollständiger Kopie und anschließendem Live-Strom ergibt einen lückenlosen Datenbestand.
Konsistenter Übergang
Der Übergang ist der heikelste Punkt: Die Snapshot-Position (bei MySQL die Binlog-Position, bei PostgreSQL die WAL-Position) wird als Startpunkt für den Stream gemerkt. Beginnt der Stream zu früh, gehen Änderungen verloren; beginnt er zu spät, werden Zeilen doppelt geliefert. Bewährte Konnektoren lösen das über einen stabilen Cutoff und prüfen, dass zwischen Snapshot-Beginn und Stream-Start geänderte Zeilen erkannt und korrekt nachgeliefert werden.
Snapshot-Modi
Debezium kennt mehrere Modi: initial (Standard: Snapshot + Stream), when_needed (nur bei Bedarf nachsnapshotten), schema_only (nur die Struktur, keine Daten) und never. Bei sehr großen Tabellen kann der Snapshot parallelisiert werden; Replication Slots oder Binlog-Positionen sichern dabei die Fortsetzung.
Verwandte Grundlagen: Log-basierte CDC, Event Stream, Datenbank-Replikation.