Konzeptionelle Frage - Datenabgleich

[Incocnito]

Hi!

Ich wollte mal hiermit fragen, was ihr für Ideen hättet:
Es sollen Daten zwischen verschiedenen Standorten abgeglichen werden.
Beispielsweise soll ein neu angelegter Kunde aus einem Standort
auch an einen anderen übertragen werden.
Wir haben uns hier in der Firma natürlich auch schon was überlegt,
aber ich wollte mal in die Runde fragen, auf was für Ideen ihr kommen
würdet? Was uns (parallel auch) noch eingefallen ist, war das Stichwort
"Replication-Server", vielleicht weiß jemand ob das in dem Zusammenhang
relevant ist und falls ja wo man idiotensicher ( ;-) ) erfährt
wie das funktioniert.
Es soll möglich sein, dass an beiden Standorten
"gleichzeitig" Kunden (und natürlich auch andere Daten, aber das wäre
dann ja übertragbar) angelegt werden können und diese dann
untereinander abgeglichen werden. Es gibt ja sicher auch hier
State-Of-The-Art-Lösungen, aber welche wäre das?

Als Datenbank dient MariaDB (also so ähnlich wie MySQL),
zum "drauf schauen" nehmen wir "HeidiSQL" (falls das überhaubt relevant ist)
und zum Entwickeln Delphi 10.2 mit MyDac auf Windows 10 x64.

Ich hoffe ich habe alle interessanten Infos genannt und freue mich auf
Hinweise, Links, Ideen, Vorschläge und all' das woran ich gerade nicht denke!

Vielen Dank schonmal für die Mühe und Zeit!

Liebe Grüße und euch allen schonmal einen wunderschönen Tag
Incocnito

[timog]

Replication ist da sicher das richtige Stichwort und die Doku von MariaDB gibt ja auch eine grobe Übersicht dazu. Erfahrung habe ich persönlich nur mit MS SQL Replikation, kann also leider nicht viel bei MariDB weiterhelfen.

[TigerLilly]

Replikation ist eine Einbahnstraße, das hilft dir hier nicht unbedingt. Du brauchst eher Synchronisation.

Hier gibt es einen Ansatz dazu:
https://www.hagenfragen.de/linux-tip...?cn-reloaded=1

Diese Fragen solltest du aber beantworten können, bevor du an eine Umsetzung gehst:
- Wir erkennst du, ob ein Datensatz (Kunde, Artikel, etc), der in DB A neu ist, bereits in einer anderen DB vorhanden ist.
- Was passiert bei so einer Kollision? Wird auf Feldebene gemerged Oder der ganze Satz übernommen?
- Können Kollisionen überhaupt auftreten?
- Wie oft werden Kollisionen auftreten?
- Wie lange können Synchronisationen im Status "pending" bleiben? Je kürzer desto besser, weil sonst die Wahrscheinlichkeit, dass der Satz in anderen DBs auch angelegt wird, steigt.
- Gibt es zyklische Abhängigkeiten? Beispiel: In DB A kann Kunde X gelöscht werden, weil er noch keine Buchungen hat. In DB B darf er aber nicht gelöscht werden, weil es schon Buchungen gibt. Stichwort: verteilte Transaktionen.

Grobkonzept:
Ich würde eine Tabelle machen:
- Database
- Kennzeichen Insert/Update/Delete
- Tabelle
- Feld
- Inhalt
- Timestamp
- Kennzeichen ob schon gesynct
- Applied

Jede Änderung wird lokal in der Tabelle mitgeschrieben.
Wenn du Syncst, holst du dir aus allen anderen DBs diese Inhalte + duplizierst sie in deine Tabelle (dort Status setzen!). Dann arbeitest du dich in chronologischer Reihenfolge durch (Applied:=Y).

Wie oft du syncst + ob die das syncen bei einem anderen anstoßen kannst, sind Details.
Wahrscheinlich musst du Löschen gesondert behandeln, siehe oben.

[rapante]

Hallo,
wie sind denn deine Standorte untereinander verbunden? Welche Latenzen sind da vorhanden?

Wir haben bei uns seit Jahren einen global erreichbaren Master-Mysql-Server auf dem alle Schreibvorgänge stattfinden und je Ort einen Slave-Server der für die Lese-Zugriffe zuständig ist.
Fällt der Master-Server aus, kann allerdings niemand mehr Änderungen tätigen. Langfristig planen wir auf eine Master-Master Replikation umzusteigen. Bisher haben wir damit leider keine Erfahrung.

[hoika]

Hallo,
Replication=Synchronisation, wenn ich in beide Richtungen replizieren.

Wichtig sind verschiedene Nummernkreise für die DB-Ids.
Jeder Standort einen anderen.

Bsp: Kunden-Id
Standort1: 1-1.000.000
Standort2: 1.000.001-2.000.000

Dann finden schon mal keine unschönen Kollisionen bei den Primary Keys auf DB-Ebene statt.
Logische Kollisionen (doppelte Kundennummer) müssen intelligent gelöst werden.

Die anderen Vorschläge (Änderungstabelle) sind genau richtig.
So hatte ich das damals mal unter Firebird bei einem Kunden implementiert.
Das Füllen der Tabelle erfolgt sinnvollerweise durch die DB selbst (Trigger).

Hier noch ein Link zum IBReplicator-Handbuch für grundlegende Sachen
http://www.ibphoenix.com/downloads/i...ator_2_5_2.pdf

[p80286]

Ich hatte auch einmal das "Vergnügen" eine LotusNotes DB vertretungsweise zu betreuen. Bei der Replizierung traten immer wieder Fehler auf, die nur durch Handarbeit zu beheben waren. Das hierfür intime Kenntnisse der Inhalte nötig waren, war den Benutzern nicht klar, dementsprechend unwirsch reagierten sie auf Anfragen nach den "richtigen" Daten. Seither bevorzuge ich zentrales DB-Schreiben.

Gruß
K-H

[Rollo62]

Zitat:

Bsp: Kunden-Id
Standort1: 1-1.000.000
Standort2: 1.000.001-2.000.000

Nimmst du dafür wirklich Integer, oder sind das Strings ?

Das ist eine interessante Frage welche "Primary keys" man am Besten nutzen sollte,
diese Frage kommt bei mir auch schonmal ab und an auf.

Normalerweise nehme ich gerne Integer, aber zum Synchronisieren mit mehreren verteilten Systemen wäre TGuid eigentlich besser geeignet, oder eine Art von Timestamp mit ID ?
Könnte man Alles auch als String abbilden, aber das wäre wohl schlecht für die Performance.
Gibt es noch bessere Alternativen, z.B. zusammengesetzte Columns, etc. ?

Ich habe bisher den echten GUID noch nicht dafür eingesetzt, könnte es vielleicht irgendwelche Probleme damit geben (z.B. doppelte ID's) ?

Rollo

[mkinzler]

BigInt mit unterschiedlichen Initialwerten der Sequenzen sollte ausreichend sein.

[TigerLilly]

Ganz vergessen:
https://www.tmssoftware.com/site/tmsecho.asp

[hoika]

Hallo,
ich hatte Integer benutzt.