Datenbestand / Master-Master-Sync

[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 von Uwe Raabe:

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 von 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?

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 von jobo:

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
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 von BUG:

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

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

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 von 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.

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)