Sie sind nicht angemeldet.

Was passiert, wenn ein Server in einem Replikationsnetz zurück gespielt wird?

Lieber Besucher, herzlich willkommen bei: MEDICAL OFFICE - Anwenderforum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

T.Sikinger

  • »T.Sikinger« ist der Autor dieses Themas

Beiträge: 62

Wohnort: Kaiserslautern

  • Nachricht senden

1

Mittwoch, 19. Januar 2022, 14:04

Was passiert, wenn ein Server in einem Replikationsnetz zurück gespielt wird?

Guten Tag,

Folgende Situation:
Wir haben ein Netz mit 5 Servern, ein Hauptserver, 4 Nebenstellen. Die 4 Nebenstellen replizieren mit dem Hauptserver.
1. Was passiert wenn nun eine Nebenstelle ausfällt und auf ein 1 Tag oder älteres Backup zurückgesetzt wird.
2. Was passiert wenn der zentrale Hauptserver ausfällt und auf ein 1 Tag oder älteres Backup zurückgesetzt wird.
-> Was ich meine ist, was wenn der Status der Datenbank des Servers schon auf z.B. 15 Uhr stand und dann spielt man eine Datenbank von 8 Uhr morgens ein, z.B.

Synchronisiert sich der "Schwarm" dann automatisch oder gibt das Probleme?

HSH KL

Beiträge: 170

Wohnort: Kaiserslautern

  • Nachricht senden

2

Mittwoch, 19. Januar 2022, 14:29

Hallo,
das wird Probleme geben (Asynchrone Datenbank) und sollte wirklich nur von einem Servicepartner oder zumindest in Zusammenarbeit mit einem Servicepartner durchgeführt werden, der die Stolpersteine kennt!
Nach §75b Abs. 5 SGB V zertifizierter IT-Dienstleister in Kaiserslautern (KBV IT-Sicherheitsrichtlinie)

pquick

Beiträge: 3 534

Wohnort: Plauen

  • Nachricht senden

3

Mittwoch, 19. Januar 2022, 15:30

Das wird mit Sicherheit erhebliche Probleme geben und so nicht funktionieren.

Einen defekten Mobilclient müssen Sie neu aufsetzen, was recht schnell geht (gehen kann).

Einen defekten Server bei intakten Daten auf einem Mobilclient kann entweder der FLS (wenn er gut ist) wieder herstellen, auf jeden Fall aber der SLS. Selbst würde ich das nie versuchen und auch keinem dazu raten…

T.Sikinger

  • »T.Sikinger« ist der Autor dieses Themas

Beiträge: 62

Wohnort: Kaiserslautern

  • Nachricht senden

4

Donnerstag, 20. Januar 2022, 09:55

Das hatte ich mir gedacht, Hintergrund war folgender:
Fällt ein Server in einer Praxis aus und ich muss den komplett neu aufsetzen und replizieren dauert das bei unserer 240GB Datenbank locker einen Tag.
Könnte ich ein Backup von der Nacht aufspielen, das lokal vorliegt ginge das innerhalb von 30 Minuten aber bevor ich sowas in unserer Infrastruktur einrichte dachte ich mir frage ich lieber mal.
PS: Es geht nicht um Mobilclients sondern volle MO Server, welche in unseren Sattelitpraxen stehen und sich via VPN replizieren.

pquick

Beiträge: 3 534

Wohnort: Plauen

  • Nachricht senden

5

Donnerstag, 20. Januar 2022, 10:05

Also wenn Sie echte Notfall-Server definiert haben dürfte der Ausfall eines Servers kein Problem sein, dann sollten Sie normal weiterarbeiten können. Das "Reparieren" des Hauptservers ist aber weiterhin nicht so ohne weiteres möglich. Das Zurückspielen eines Backups wird definitiv die gesamte Replikations-Architektur durcheinanderbringen

rothsching

Beiträge: 720

Wohnort:

  • Nachricht senden

6

Donnerstag, 20. Januar 2022, 10:41

Zitat von »pquick«

Das wird mit Sicherheit erhebliche Probleme geben und so nicht funktionieren.

Einen defekten Mobilclient müssen Sie neu aufsetzen, was recht schnell geht (gehen kann).

Einen defekten Server bei intakten Daten auf einem Mobilclient kann entweder der FLS (wenn er gut ist) wieder herstellen, auf jeden Fall aber der SLS. Selbst würde ich das nie versuchen und auch keinem dazu raten…
Das sehe ich absolut genauso. Ich mache auch viel selbst und bin bei allen Servicearbeiten dabei, aber bei Datenbankthemen bin ich froh, dass mein Servicepartner da mehr Ahnung und vor allem Routine hat.
Mit freundlichen Grüßen

M. Rothsching

pquick

Beiträge: 3 534

Wohnort: Plauen

  • Nachricht senden

7

Donnerstag, 20. Januar 2022, 12:47

Zitat von »T.Sikinger«

unserer 240GB Datenbank locker einen Tag.
Hier noch ein später Gedanke:

Da macht es bei Ihnen Sinn, auf die Speicherung im Dateisystem zu gehen. Damit wird die MO-Datenbank sehr klein und die vielen kleinen ausgelagerten Dateien lassen sich viel besser incrementell sichern. Auch im Falle eines Datenbank-Crashs sind die Dateien immer noch vorhanden, nur neue Dateien müßten ergänzt werden...

T.Sikinger

  • »T.Sikinger« ist der Autor dieses Themas

Beiträge: 62

Wohnort: Kaiserslautern

  • Nachricht senden

8

Donnerstag, 20. Januar 2022, 15:04

Zitat von »pquick«

Da macht es bei Ihnen Sinn, auf die Speicherung im Dateisystem zu gehen.

als ich das zum test mal eingerichtet hatte wurde die archivdatenbank nicht gesichert.
Unsere medoff.gdb hat 80GB, die medoffarc.gdb die restlichen 160GB
Bei einer Widerherstellung in der Datenpflege kommt dann aber genau die geschilderte Problematik zum tragen, dass ein Server ja in der Zeit zurückgesetzt wird.

Im hintergund benutzt MO ja auch nur gbak oder nBackup.

pquick

Beiträge: 3 534

Wohnort: Plauen

  • Nachricht senden

9

Donnerstag, 20. Januar 2022, 18:41

Zitat von »T.Sikinger«

als ich das zum test mal eingerichtet hatte wurde die archivdatenbank nicht gesichert.
Das kann man im Aktivsystem nicht testweise einrichten, das Ganze ist dann dauerhaft.

Es gibt danach keine Archiv-GDB mehr, d.h. Sie brauchen Sie nicht mehr. Sie können sie dann noch einmalig für später extern speichern, aber alle Altbefunde und auch alle dann neuen Befunde finden sich nach der Umstellung im Dateisystem. Natürlich müssen Sie diese Ordner mit Unterordnern sichern, aber das kann ja jedes fortgeschrittene Backupsystem problemlos und Sie müssen auch nicht mehr die Datenbank sperren, wenn Sie das Dateisystem sichern. Gerade für Ihre große Datenmenge sehe ich eigentlich nur Vorteile. Würde ich mal mit Ihrem FLS besprechen...

Angesichts der Datenmenge werden Sie aber einen Arbeitstag für die Umstellung einplanen müssen, evtl. Wochenende oder im Urlaub planen

Hus Brogarden

Beiträge: 2 225

Wohnort: :)

Über mich:

ich bin TI ready, sowas von ready, aber keiner meine Kunden macht mit

  • Nachricht senden

10

Samstag, 22. Januar 2022, 16:52

Ich frag jetzt mal blöd.
Wenn man so eine große Praxis hat, mit vielen Standorten, aber eine gemeinsame Abrechnung und vielen GB Datenbank, also 250 GB.
Da muss es doch ein System geben, dass man ohne Zutun, ohne Arbeit, ohne Nervkram und VES, wenn einmal eingerichtet, niemals nicht eine einzige Patienteninfo verliert.
Wir fahren mit 2 Ärzten so, dass wir notfalls einen 1/2 Tag verlieren, alles andere lohnt sich nicht.
Aber bei Großpraxen muss es doch eine idiotensichere und vermutlich auch teure Lösung geben, die sich dann auch amortisiert.
bro

pquick

Beiträge: 3 534

Wohnort: Plauen

  • Nachricht senden

11

Samstag, 22. Januar 2022, 21:39

Nennt sich doch Notfall-Server!

Der ist immer synchronisiert (optimalerweise) und somit kann die Datenbank problemlos ohne Verlust wiederhergestellt werden.

Und wie gesagt, bei so großen Datenbanken macht es Sinn, eine Auslagerung in das Dateisystem durchzuführen. Das ist nicht zu verwechseln mit der Archivierung in die arc-Datei!! Sondern es werden wirklich alle Dateien im Archiv (Bilder, Scans, etc) in das externe Windows-Dateisystem ausgelagert und auch synchronisiert. Das macht das Back-up deutlich einfacher und die Haupt-Datenbank viel schlanker. Bei mir waren es nachher statt 27GB nur noch 3 GB…

T.Sikinger

  • »T.Sikinger« ist der Autor dieses Themas

Beiträge: 62

Wohnort: Kaiserslautern

  • Nachricht senden

12

Dienstag, 25. Januar 2022, 15:13

Zitat von »Hus Brogarden«

Da muss es doch ein System geben, dass man ohne Zutun, ohne Arbeit, ohne Nervkram und VES, wenn einmal eingerichtet, niemals nicht eine einzige Patienteninfo verliert.

Das System gibt es in der Tat und es nennt sich Medical Office. Wenn ein Server ausfällt haben wir ja noch 4 mit aktueller Datanbank. Es gehen höchstens Dinge der letzten Minute verloren, je nachdem wie schnell die Replikation ist.
Das Wiederherstellen eines Servers kann hier aber Stunden bis Tage dauern, wenn man diesen aus den anderen Datenbanken wiederauferstehen lassen muss. Darum war auch meine Frage ob ich einfach ein Serversnapshot einspielen kann, auch wenn dieses ein paar Stunden zurück liegt. Ob das die Datenbank erkennt und synchonisiert.
Hier geht es nicht um Datenverlust, der ist ausgeschlossen, vielmehr möchte ich die Zeit, die zur Wiederherstellung eines Knotens gebraucht wird auf ein minimum reduzieren. Idealerweise bis hin zur nahtlosen Wiederherstellung.

T.Sikinger

  • »T.Sikinger« ist der Autor dieses Themas

Beiträge: 62

Wohnort: Kaiserslautern

  • Nachricht senden

13

Dienstag, 25. Januar 2022, 15:20

Zitat von »pquick«

Das ist nicht zu verwechseln mit der Archivierung in die arc-Datei!! Sondern es werden wirklich alle Dateien im Archiv (Bilder, Scans, etc) in das externe Windows-Dateisystem ausgelagert und auch synchronisiert.
Ich muss hier leider anmerken, dass sich jeder Admin in seinem hypothetischen Grabe umdrehe, wenn man erwähnt Datenbanken als Flatfiles umzusetzen. Es mag sein, dass das funktioniert, wir hatten aber auch den Sprung von IFA Systems zu MO gemacht um genau das nicht mehr zu haben. Windows Dateisysteme sind viel fehlernafälliger und manipulierbarer als eine ordentliche Datenbank. Zudem ist der Zugriff auf eine solche Datenstruktur sehr langsam, besonders bei Windows.

Dies ist also keine Option für uns. Archivierung in die Arc Datei ist eine wesentlich sauberere Herangehensweise und Backups gehen hier viel, viel schneller als bei mehreren millionen einzelnen, kleinen Dateien in einem Windows Dateisystem (vorrausgesetzt man nutzt Firebirds nBackup Funktion ordentlich)

pquick

Beiträge: 3 534

Wohnort: Plauen

  • Nachricht senden

14

Dienstag, 25. Januar 2022, 20:44

Darüber kann man sicherlich geteilter Meinung sein… ich wollte nur etwas vorschlagen, mit dem ich gut zurechtkomme. Mein Datenbanksystem ist nicht langsamer als zuvor (SSD).


Ich mache Gesamtbackups immer als Backup der Partition, damit entfällt das Problem der vielen kleinen Dateien. Und zur externen Sicherung auf mein NAS zu Hause nutze ich Resilio, was eben immer nur die neu dazugekommenen Dateien überträgt. Das wäre mit einer 30 GB-Datenbank unmöglich gewesen, auch bei einer 100 MBit Leitung. Incrementelle Sicherungen einer großen Datenbank wie Ihrer mit 700 GB wären mir unbekannt…. Für solche Dateigrößen bräuchte man vermutlich andere Datenbank-Systeme.

Von daher bin ich zufrieden, jeder muß für sich seine eigene Lösung finden

Grüße,

P. Quick

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »pquick« (26. Januar 2022, 15:50)

GMPTS

Beiträge: 528

Wohnort: D

  • Nachricht senden

15

Dienstag, 25. Januar 2022, 21:28

Hallo,
hiermit helfen Sie mir weiter:

Zitat von »T.Sikinger«

Ich muss hier leider anmerken, dass sich jeder Admin in seinem hypothetischen Grabe umdrehe, wenn man erwähnt Datenbanken als Flatfiles umzusetzen. Es mag sein, dass das funktioniert, wir hatten aber auch den Sprung von IFA Systems zu MO gemacht um genau das nicht mehr zu haben. Windows Dateisysteme sind viel fehlernafälliger und manipulierbarer als eine ordentliche Datenbank. Zudem ist der Zugriff auf eine solche Datenstruktur sehr langsam, besonders bei Windows.



Dies ist also keine Option für uns. Archivierung in die Arc Datei ist eine wesentlich sauberere Herangehensweise und Backups gehen hier viel, viel schneller als bei mehreren millionen einzelnen, kleinen Dateien in einem Windows Dateisystem (vorrausgesetzt man nutzt Firebirds nBackup Funktion ordentlich
ich weiß das war hier garnicht Grundfrage ihres threads aber sie haben mir ein paar Blickwinkel eröffnet die ich noch garnicht kannte und die ich eigentlich hier Dokumentenspeicherung im Dateisystem versuchte zu entdecken - Danke dafür
daher wenn okay gleich noch eine Frage an "Ihrem Thema hier" vorbei - ab welcher Größe der medoff.gdb denken Sie darüber nach die selbige in die medoffarc.gdb zu archivieren - also wann wird Ihnen die medoff.gdb "zu groß" bzw. dauert nBackup Ihnen zu lange?

H.Rügen

Beiträge: 514

Wohnort: Schwerin

  • Nachricht senden

16

Mittwoch, 26. Januar 2022, 15:39

Zitat von »T.Sikinger«

Zitat von »pquick«

Das ist nicht zu verwechseln mit der Archivierung in die arc-Datei!! Sondern es werden wirklich alle Dateien im Archiv (Bilder, Scans, etc) in das externe Windows-Dateisystem ausgelagert und auch synchronisiert.
Ich muss hier leider anmerken, dass sich jeder Admin in seinem hypothetischen Grabe umdrehe, wenn man erwähnt Datenbanken als Flatfiles umzusetzen. Es mag sein, dass das funktioniert, wir hatten aber auch den Sprung von IFA Systems zu MO gemacht um genau das nicht mehr zu haben. Windows Dateisysteme sind viel fehlernafälliger und manipulierbarer als eine ordentliche Datenbank. Zudem ist der Zugriff auf eine solche Datenstruktur sehr langsam, besonders bei Windows.

Dies ist also keine Option für uns. Archivierung in die Arc Datei ist eine wesentlich sauberere Herangehensweise und Backups gehen hier viel, viel schneller als bei mehreren millionen einzelnen, kleinen Dateien in einem Windows Dateisystem (vorrausgesetzt man nutzt Firebirds nBackup Funktion ordentlich)

Zitat von »T.Sikinger«

Zitat von »pquick«

Das ist nicht zu verwechseln mit der Archivierung in die arc-Datei!! Sondern es werden wirklich alle Dateien im Archiv (Bilder, Scans, etc) in das externe Windows-Dateisystem ausgelagert und auch synchronisiert.
Ich muss hier leider anmerken, dass sich jeder Admin in seinem hypothetischen Grabe umdrehe, wenn man erwähnt Datenbanken als Flatfiles umzusetzen. Es mag sein, dass das funktioniert, wir hatten aber auch den Sprung von IFA Systems zu MO gemacht um genau das nicht mehr zu haben. Windows Dateisysteme sind viel fehlernafälliger und manipulierbarer als eine ordentliche Datenbank. Zudem ist der Zugriff auf eine solche Datenstruktur sehr langsam, besonders bei Windows.

Dies ist also keine Option für uns. Archivierung in die Arc Datei ist eine wesentlich sauberere Herangehensweise und Backups gehen hier viel, viel schneller als bei mehreren millionen einzelnen, kleinen Dateien in einem Windows Dateisystem (vorrausgesetzt man nutzt Firebirds nBackup Funktion ordentlich)

Hallo Zusammen,
solche pauschalisirten und falschen Aussagen halte ich hier nicht für zielführend. Bitte besser mit dem Thema beschäftigen. Sonst werden die Anwender nur verunsichert.
MfG H.Rügen

GMPTS

Beiträge: 528

Wohnort: D

  • Nachricht senden

17

Mittwoch, 26. Januar 2022, 17:04

Hallo Herr Rügen,

Zitat von »H.Rügen«

Bitte besser mit dem Thema beschäftigen.
Ich als Anwender würde das gern tun - auch weil ich davon ausgehe dass es verschiedene Sichtweisen gibt. Einige Kernfragen hierzu habe ich versucht hier Dokumentenspeicherung im Dateisystem zu stellen.

T.Sikinger

  • »T.Sikinger« ist der Autor dieses Themas

Beiträge: 62

Wohnort: Kaiserslautern

  • Nachricht senden

18

Donnerstag, 27. Januar 2022, 09:30

Zitat von »H.Rügen«

solche pauschalisirten und falschen Aussagen halte ich hier nicht für zielführend.

Dies zeigt doch nur auf, dass hier Klärungsbedarf besteht, zudem wäre es doch sehr nett zu erfahren wass hier eine Falschaussage gesewen sein sollte. Ihre Antwort ist leider ebenfalls sehr pauschalisiert. Welche Aussage stimmt denn nicht?
Eine genaue Antwort von Indamed auf meine initiale Frage habe ich auch noch nicht erhalten.

Ähnliche Themen

Verwendete Tags

Backup, replication, zurücksetzen