Datenbestand / Master-Master-Sync

[FAM]

Hallo Zusammen,

ich versuche gerade eine (gesunde) Logik zu entwicklen ...

Umgebung:
2 Programme auf jeweils unterschiedlichen Rechner.
PC (#1)
PC (#2)

Laufzeit:
Jedes Programm schreibt in zyklichen Abständen ein Datenbestand in eine binär Datei.
Datei (A)
Datei (B)

Problemstellung:
Die beiden Programme (PC #1: A & PC #2: B) müssen jeweils die andere Binär-Datei auf ihre Aktualität prüfen,
wenn ein Datenbestand nicht mehr aktuell (PC #1: A != PC #2: B) ist muss die inaktuelle-Datei mit der aktuellen Datei ersetzt werden

Bedingung:
Es darf kein Masterprogramm implmentiert werden, welches die eigentliche Überwachung vornimmt.


Um das mal zu verbildlichen habe ich ein Screenshot angehangen.
Hat jemand einen passenden Lösungsvorschlag?

[Uwe Raabe]

Nehmen wir an, die beiden Dateien sind aktuell synchron. Jetzt ändern beide Programme zur gleichen Zeit an ihrer jeweiligen Datei etwas. Welche gilt dann als aktuell?

[FAM]

Hallo Uwe,

das ist genau das Grundproblem, daher würde ich über den Zeitstempel gehen.
Ist Änderungs-Zeit einer Datei (A||B) < Faktor X dann gilt diese als inaktuell und muss überschrieben werden

Zeitstempl-Ansatz
If timestamp(PC #1: A) < 1 min then copy PC #2: B > PC #1: A

Es müssen also nicht die Inhalte ansich geprüft werden ...

Hast du einen anderen Ansatz?

[p80286]

Zunächst würde ich dies über eine Zentraldatei/Datenbank lösen.
Bleibt die Frage, waß passiert wenn beide zum genau gleichen Zeitpunkt schreiben wollen?

Gruß
K-H

[Uwe Raabe]

Wenn ich das richtig verstehe, dann sind die Änderungen von dem einen PC dann verloren, wenn die "aktuelle" Datei vom anderen PC übernommen wird?

Wie kommunizieren die PCs untereinander?

[BUG]

Zitat:

Zitat von Uwe Raabe (Beitrag 1286046)

Wie kommunizieren die PCs untereinander?

Es gibt noch andere interessante Randbedingungen:

• Sind es im Normalfall immer nur 2 PCs?
• Läuft das Programm ständig?
• Wie robust muss das Protokoll sein (Ausfall eines oder beider Rechner)?
• Kannst du die Programmme ändern oder musst du ein zusätzliches Tool schreiben, dass die Synchronisierung übernimmt?

[Dejan Vu]

Was ist dein Grundproblem? Ich vermute: Die PCs messen irgend etwas und mal ist der eine PC an und mal der andere, oder? D.h. der Normalfall ist das *entweder* A *oder* B aktiv ist.

Dann reicht es, beim Programmstart einmalig zu prüfen, ob die jeweils andere Datei aktueller als die eigene ist und die dann zu sich selbst kopieren:

Delphi-Quellcode:

If Timestamp(TheOtherFile) > TimeStamp(MyOwnFile) + ThresHold then
  Copy (TheOtherFile, MyOwnFile);

StartTheMeasurements;

In einer Konfigurationsdatei definierst Du jeweils 'TheOtherFile' und 'MyOwnFile'.

Bei dieser Konfiguration könnte es auch reichen, ein gemeinsames Netzlaufwerk zu nehmen und dort einfach eine Datei zu beschreiben. Der 2.PC macht dann einfach nichts, solange der erste noch aufzeichnet.

Bei einem andere Szenario (d.h. beide messen irgend etwas) würde das aber auch funktionieren, nur das man das Schreiben mit Sperrmechanismen schützen könnte. Dann überschreibt eben der eine die aktuellen Daten des anderen, oder hängt es hinten ran. Das nennt sich dann 'Datenbank' und ist eh die bessere Wahl.

[jobo]

Zitat:

Zitat von p80286 (Beitrag 1286045)

Zunächst würde ich dies über eine Zentraldatei/Datenbank lösen.
Bleibt die Frage, waß passiert wenn beide zum genau gleichen Zeitpunkt schreiben wollen?

:thumb:
Auch mir scheint das ein klassischer Fall für eine DB zu sein, auch wenn es die Anforderung gibt, dass es kein 3. Programm zur Überwachung geben darf.
Angenommen, es wird keine DB verwendet, wie soll das ein oder andere Detail gelöst werden:
- Schreib/Lesevorgänge: Wie wird die Datei geschrieben? Sequentiell, vollständig, ..
- Dateigröße: Ab einer gewissen Größe entstehen deutliche Laufzeiten für den Schreibvorgang, die Berücksichtigt werden müssen.
- Daraus folgend sind ggF. beim Schreiben die jeweils andere Datei zu sperren o.ä.
- .. weiteres?
Das sind Probleme, für die Datenbanksysteme gemacht sind und die dort bereits gelöst sind.

[BUG]

Zitat:

Zitat von jobo (Beitrag 1286122)

Das sind Probleme, für die Datenbanksysteme gemacht sind und die dort bereits gelöst sind.

Wenn ich das richtig beobachtet habe, müssen gerade unter den Delphianern einige mit Kunden arbeiten, die eine merkwürdige IT-Umgebung und einen kautzigem Admin haben, der dort alle Regeln macht :mrgreen:
Da heißt es dann: Datenaustausch nur über NAS/FTP/Diskette ... friss oder stirb!

[jobo]

Ja, mag ja sein. Dann muss man dem Kunden eben auch sagen, dass er die Wahl hat zwischen
a) liebevoll selbst gestrickt, entlang der Kundenanforderung und den 5 Problembereichen, die einem aus der eigenen Erfahrung und der Literatur über den Weg gelaufen sind. Hausgemachte Tests mit 2 Testern in 3 verschiedenen Szenarien.
oder
b) jahrzehntelang ausgereifte RDBMS Software seiner Wahl, auf Wunsch ohne Lizenzkosten, ACID konform, Transaktionskonzept, millionenfach betrieben und getestet, auf Wunsch auch mit Win8, 9, 10, 11, .. Garantie etc. pp.

Als Beispiel für Variante a) würde ich die Sperrdatei der BDE nehmen. Ich glaub, da sind professionell direkt mehrere Probleme unberücksichtigt geblieben.

[Sir Rufo]

Möglichkeit 1:

Es wird ein Locking benötigt, der zuverlässig das Schreiben von nur einer Stelle zulässt.

Möglichkeit 2:

Erzeugen von einem Transaktionslog, was dann auf jede Datei angwendet wird.

[p80286]

Zitat:

Zitat von BUG (Beitrag 1286124)

Wenn ich das richtig beobachtet habe, müssen gerade unter den Delphianern einige mit Kunden arbeiten, die eine merkwürdige IT-Umgebung und einen kautzigem Admin haben, der dort alle Regeln macht :mrgreen:

Die haben keinen Admin sondern einen Chef der die C..p liest.:mrgreen:

Aber im Ernst, die Frage ist doch, welchen Zweck soll die Konstellation erfüllen? Da anzusetzen scheint mir u.U. sinnvoller als an Symptomen herum zu doktern.

Gruß
K-H

[FAM]

Hallo Zusammen,

erstmal danke für eure antworten....

zu euren Fragen / Randbedingungen

- Schreib/Lesevorgänge: Wie wird die Datei geschrieben? Sequentiell, vollständig, ..
Vollständig

- Dateigröße: Ab einer gewissen Größe entstehen deutliche Laufzeiten für den Schreibvorgang, die Berücksichtigt werden müssen.
Dateigrösse max. 1 MB

- Daraus folgend sind ggF. beim Schreiben die jeweils andere Datei zu sperren o.ä.
nicht notwendig, den das eigentliche Beschreiben der Binär-Datei und der zu implmentierende Sync laufen parallel (Datei wird geschrieben und im Hintergrund - Thread?! - läuft der Sync respektive die Überwachung über Sync notwendig)

- Sind es im Normalfall immer nur 2 PCs?
ja,

- Läuft das Programm ständig?
ja

- Wie robust muss das Protokoll sein (Ausfall eines oder beider Rechner)?
wenn ein PC ausfällt soll der zweite einspringen

- Kannst du die Programmme ändern oder musst du ein zusätzliches Tool schreiben, dass die Synchronisierung übernimmt?
kann das programm ändern

Zitat:

Zitat von Sir Rufo (Beitrag 1286126)

Möglichkeit 1:

Es wird ein Locking benötigt, der zuverlässig das Schreiben von nur einer Stelle zulässt.

Möglichkeit 2:

Erzeugen von einem Transaktionslog, was dann auf jede Datei angwendet wird.

wie würdest du diesen Transaktionslog konzipieren/implmentieren?



Implementierungsgrund ist eine Daten-Redundanz:

2 PCs laufen ständig (in einem Netzwerk) und haben jeweils einen und den selben Client am laufen, die jeweiligen Clients beziehen von ein und der selben Quelle Daten und schreiben diese dann in eine *.dat Datei (2 x 1:1 Beziehungen - Client vs. OPC-Server).

Falls mal ein Client aus ist (z.B. Absturz) und er wieder angestellt wird, muss geprüft werden ob die Daten der *.dat (auf den PC welcher gerade abgestürzt war) "noch aktuell sind" > an dieser Stelle müsste dann der Sync laufen (Copy *.dat von anderne PC). Eine andere Möglichkeit warum bedarf von einem Sync besteht ist wenn z.B. der Client die Daten vom OPC-Server nicht richtig lesen konnte ...

Auf beiden PC soll einfach eine 100% Datengleichheit bestehen, zu jeder Zeit.

Eine Datenbank ist auszuschliessen! (Kundenwusch)

[p80286]

Zitat:

Zitat von FAM (Beitrag 1286282)

- Dateigröße: Ab einer gewissen Größe entstehen deutliche Laufzeiten für den Schreibvorgang, die Berücksichtigt werden müssen.
Dateigrösse max. 1 MB

Auf welchem Medium mußt Du speichern? Diskette?

Zitat:

Zitat von FAM (Beitrag 1286282)

- Daraus folgend sind ggF. beim Schreiben die jeweils andere Datei zu sperren o.ä.
nicht notwendig, den das eigentliche Beschreiben der Binär-Datei und der zu implmentierende Sync laufen parallel (Datei wird geschrieben und im Hintergrund - Thread?! - läuft der Sync respektive die Überwachung über Sync notwendig)

- Sind es im Normalfall immer nur 2 PCs?
ja,

- Läuft das Programm ständig?
ja

- Wie robust muss das Protokoll sein (Ausfall eines oder beider Rechner)?
wenn ein PC ausfällt soll der zweite einspringen

Da stimmt etwas nicht, entweder arbeiten beide PCs immer, dann springt keiner ein, oder aber einer ist der "Verantwortliche" und PC2 übernimmt wenn PC1 ausfällt.

Zitat:

Zitat von FAM (Beitrag 1286282)

Auf beiden PC soll einfach eine 100% Datengleichheit bestehen, zu jeder Zeit.

Das kannst Du vergessen, am Ende eines Tages, zu jeder vollen Stunde, zu jeder vollen Minute, das kann gehen aber zumindest während des Zeitraums einer möglichen Synchronisation sind die beiden Dateien nicht gleich.

Zitat:

Zitat von FAM (Beitrag 1286282)

Eine Datenbank ist auszuschliessen! (Kundenwusch)

Dann hoffen wir mal das der Kunde weiß wovon er spricht:roll:

Gruß
K-H

[FAM]

Zitat:

Auf welchem Medium mußt Du speichern? Diskette?

HDD

Zitat:

Da stimmt etwas nicht, entweder arbeiten beide PCs immer, dann springt keiner ein, oder aber einer ist der "Verantwortliche" und PC2 übernimmt wenn PC1 ausfällt.

das ist ja genau das thema des forum-threads... Master-Master-Sync...
Beide PC laufen ständig. Wenn sich ein Mitarbeiter an PC#1 setzt, hat er den selben Datenbestand als wenn er sich an PC#2 setzt...
Grundlegend Auslagerung der Datenkonsistenz auf beiden Rechner sinnvoller (Stichwort: Zentrale Datenhaltung), ist aber eben nicht gewünscht.

Zitat:

Das kannst Du vergessen, am Ende eines Tages, zu jeder vollen Stunde, zu jeder vollen Minute, das kann gehen aber zumindest während des Zeitraums einer möglichen Synchronisation sind die beiden Dateien nicht gleich.

das wäre ok, denn der Sync-Vorgang dauert nicht lange (Datenbestand < 1MB)

[mkinzler]

Zitat:

Falls mal ein Client aus ist (z.B. Absturz) und er wieder angestellt wird, muss geprüft werden ob die Daten der *.dat (auf den PC welcher gerade abgestürzt war) "noch aktuell sind" > an dieser Stelle müsste dann der Sync laufen (Copy *.dat von anderne PC). Eine andere Möglichkeit warum bedarf von einem Sync besteht ist wenn z.B. der Client die Daten vom OPC-Server nicht richtig lesen konnte ...

Wenn einer schon weg ist (-> fehlende Redundanz), dann gefährden wir auch noch den 2. indem wir im Betrieb die Datei Kopieren.

Zitat:

Eine Datenbank ist auszuschliessen! (Kundenwusch)

Das wäre auch noch schöner, wenn eine Chance auf Funktionieren bestehen würde.

-Warum wird immer vollständig geschrieben und nicht nur neues Angehängt?
-Warum machen 2 das Selbe? Besser Synchronisation Bestände und 2. Client nur bei Ausfall.

Die ganze Sache ist ein Himmelfahrtskommando, da es nur ein Frage der Zeit ist, bist das Kartenhaus implodiert.

[FAM]

Zitat:

-Warum wird immer vollständig geschrieben und nicht nur neues Angehängt?

ein Inkrementelles Schreiben ist überflüssig da Datenbestand sehr klein, zudem ist die Schreibroutine schon fertig implementiert.

Zitat:

-Warum machen 2 das Selbe? Besser Synchronisation Bestände und 2. Client nur bei Ausfall.

Kundenvorgabe!

[mkinzler]

Und wer haftet? Wenn Kunde das Risiko übernimmt (explizit, schriftlich; Warnung vor Problem in Vertrag).