Near-Zero-Downtime Migration von MSSQL zu PostgreSQL mit Debezium

Datenbankmigrationen können besonders bei großen Datenbanken lange Downtimes verursachen. Eine Möglichkeit, dieses Problem zu reduzieren, ist der Einsatz von Debezium. Dabei werden Änderungen aus der Quell-Datenbank erfasst und nach der initialen Datenübertragung in das Zielsystem übernommen. Dieser Beitrag zeigt anhand einer Migration vom Microsoft SQL Server zu PostgreSQL, wie sich mit Debezium und Kafka eine Architektur umsetzen lässt, bei der die Downtime der Anwendung auf wenige Minuten reduziert werden kann. 

Change Data Capture als Grundlage

Change Data Capture (CDC) ermöglicht es, Änderungen in einer Datenbank automatisch zu erkennen und weiterzugeben. Anstatt regelmäßig komplette Tabellen zu kopieren, werden nur die tatsächlichen Änderungen übertragen.

Technisch basiert CDC auf den Transaktionslogs einer Datenbank, in denen alle Änderungen protokolliert werden. Diese Änderungen werden in sogenannte Change Tables übertragen. Anschließend können sie von anderen Systemen ausgelesen und weiterverarbeitet werden.

Damit lassen sich Daten nahezu in Echtzeit zwischen verschiedenen Systemen synchronisieren, ohne die Datenbank selbst ständig abfragen zu müssen.

EXEC sys.sp_cdc_enable_db;
EXEC sys.sp_cdc_enable_table
    @source_schema = 'Schema',
    @source_name   = 'Tabellen_Name',
    @role_name     = NULL; 

Erstellung einer CDC-Tabelle im Microsoft SQL Server)

Debezium & Kafka für den Transport

Um diese Änderungen nutzbar zu machen, kommt Debezium zum Einsatz. Debezium liest die Änderungen aus den Datenbanklogs bzw. den CDC-Tabellen und erzeugt daraus sogenannte Change-Events.

Diese Events werden anschließend an Apache Kafka übertragen. Kafka fungiert dabei als zentrale Streaming-Plattform, in die diese Änderungen zuverlässig gespeichert und dann an andere Systeme verteilt werden können.

Durch diese Architektur werden Datenquelle und Zielsystem entkoppelt. Änderungen aus der Datenbank können als ein kontinuierlicher Datenstrom verarbeitet werden, ohne dass andere Anwendungen direkt auf die Datenbank zugreifen müssen.

Migrationsablauf

1. Erste Downtime – Anwendung stoppen
   Zunächst wird die Anwendung kurzzeitig gestoppt, um einen konsistenten Stand der Datenbank zu gewährleisten.
2. Backup erstellen und CDC aktivieren
   Anschließend wird ein Backup der bestehenden Datenbank auf dem Microsoft SQL Server erstellt. Gleichzeitig wird Change Data Capture (CDC) aktiviert und Debezium eingerichtet, sodass alle nachfolgenden Änderungen aus der Datenbank erfasst und an Kafka übertragen werden können.
3. Anwendung wieder starten
   Nachdem CDC und Debezium aktiviert sind, kann die Anwendung wieder gestartet werden und der reguläre Betrieb wird fortgesetzt.
4. Initiale Migration und Synchronisation der Änderungen
   Das zuvor erstellte Backup wird als Grundlage für die initiale Beladung der PostgreSQL-Datenbank verwendet. Die initiale Übertragung des Schemas und der Daten kann beispielsweise mit Tools wie Pgloader umgesetzt werden. Nach Abschluss dieser initialen Migration wird der JDBC Sink Connector aktiviert. Dieser übernimmt die Änderungen, die seit der Aktivierung von CDC entstanden sind, aus Kafka und schreibt sie in die PostgreSQL-Datenbank. Dadurch bleiben beide Systeme während des laufenden Betriebs synchron.
5. Zweite Downtime – Umschalten auf PostgreSQL
   Sobald beide Datenbanken synchron sind, wird die Anwendung erneut kurz gestoppt und die Datenbankverbindung auf PostgreSQL umgestellt.
6. Monitoring und Funktionstests
   Nach dem Start der Anwendung auf der neuen Datenbank folgen Monitoring und Funktionstests, um sicherzustellen, dass das System stabil und korrekt arbeitet.

Fazit

Datenbankmigrationen müssen nicht zwangsläufig mit langen Ausfallzeiten verbunden sein. Durch den Einsatz von Debezium lassen sich Änderungen kontinuierlich zwischen Systemen synchronisieren.

Dieser Ansatz ermöglicht es, auch große Datenbanken schrittweise zu migrieren, während die Anwendung weiterhin läuft.

Seminarempfehlungen