Technologie

Datenbank-Replikation zwischen heterogenen Systemen

Wie synchronisiert man Daten zwischen einer zentralen Datenbank und dutzenden dezentralen Stationen - wenn die Verbindung instabil ist, IDs kollidieren können und referentielle Integrität gewahrt bleiben muss?

Die Herausforderung

Instabile Verbindungen

Außenstellen wie Tankstellen oder Filialen haben oft unzuverlässige Internetverbindungen. Das System muss offline-fähig sein und bei Wiederverbindung automatisch synchronisieren.

Unterschiedliche Datenbanken

Die Zentrale nutzt Firebird (robust, bewährt), die Stationen SQLite (leichtgewichtig, embedded). Beide haben unterschiedliche Datentypen, SQL-Dialekte und Transaktionsmodelle.

ID-Konflikte

Wenn Station A einen neuen Beleg mit ID 1000 erstellt und Station B gleichzeitig auch, entstehen Kollisionen. Jede Station braucht eigene ID-Bereiche mit zentralem Mapping.

Referentielle Integrität

Ein Beleg referenziert einen Kunden, einen Artikel, einen Mitarbeiter. Wenn der Beleg vor dem Kunden ankommt, schlägt der Fremdschlüssel fehl.

Unsere Lösung: Event-basierte Replikation

Statt die gesamte Datenbank zu kopieren, tracken wir nur Änderungen. Jede INSERT, UPDATE oder DELETE Operation wird in einem Change-Log erfasst und asynchron zur Gegenstelle übertragen.

Zentrale DB Firebird
Stammdaten
Belege
Stationen SQLite

Kernkonzepte

1 Change Data Capture

Database-Trigger erfassen jede Änderung automatisch. Für jede Tabelle wird protokolliert:

  • Operation - INSERT, UPDATE oder DELETE
  • Tabelle - Welche Entität betroffen ist
  • Primärschlüssel - Welcher Datensatz
  • Zeitstempel - Wann die Änderung erfolgte

2 ID-Mapping

Jede Station hat einen eigenen ID-Raum. Ein zentrales Mapping verknüpft lokale IDs mit globalen:

Tabelle Station-ID Zentral-ID
Beleg100058723
Beleg100158724
Zahlung50091234

Bei der Übertragung werden alle IDs - auch Fremdschlüssel - automatisch umgemappt.

3 Dreiphasige Verarbeitung

FK-Abhängigkeiten erfordern eine spezielle Reihenfolge. Unser Algorithmus verarbeitet Änderungen in drei Phasen:

Phase 1

Normale Operationen

Alle INSERTs/UPDATEs/DELETEs ausführen. Fehlgeschlagene werden gepuffert.

Phase 2

Wiederholung

Gepufferte Operationen erneut versuchen - das FK-Ziel existiert jetzt möglicherweise.

Phase 3

Finale Updates

FK-Spalten aktualisieren, die in Phase 1 temporär auf NULL gesetzt wurden.

4 MQTT als Transportschicht

Für die Kommunikation mit Offline-fähigen Stationen nutzen wir MQTT (Message Queuing Telemetry Transport):

  • Leichtgewichtig - minimaler Overhead auch bei schlechter Verbindung
  • Publish/Subscribe - entkoppelte Kommunikation
  • QoS-Level - garantierte Zustellung auch bei Verbindungsabbruch

Praxisbeispiel: Tankstellen-Netzwerk

Ein Tankstellen-Betreiber mit 15 Standorten benötigt Echtzeit-Daten in der Zentrale, aber die Stationen müssen auch bei Internetausfall voll funktionsfähig bleiben.

Zentrale → Station

  • Artikelstammdaten (Preise, Bezeichnungen)
  • Kundendaten (Firmen, Kreditlimits)
  • Tankkarten und Berechtigungen
  • Preis-Korrekturen und Rabatte

Station → Zentrale

  • Tankbelege und Zahlungen
  • Rechnungen und Lieferscheine
  • Bonuskarten-Transaktionen
  • Kassenabschlüsse

Ergebnisse

100%

Offline-Fähigkeit

<5s

Sync-Latenz (online)

0

Datenverluste

Ähnliche Herausforderung?

Wir entwickeln individuelle Replikationslösungen für Ihre Anforderungen - von einfacher Master-Slave-Replikation bis zu komplexen Multi-Master-Szenarien.

Beratungsgespräch vereinbaren