HCL Notes / Domino / Diverses > Administration & Userprobleme

Hyper-V und Cluster

(1/2) > >>

Ottoderxte:
Hallo zusammen,

ich setze den Domino-Server als virtuelle Maschine auf Hyper-V im Cluster ein.
Was würde eigentlich passieren wenn ich bei einer Machine einen Prüfpunkt setze und aus versehen den Prüfpunkt anstatt zu löschen aktivieren würde.
Sprich ein Server wäre dann z.B. 2 Stunden zurück.
Würde die Replikation trotzdem alle fehlenden E-Mails wieder nachschieben oder hätte ich dann für immer eine Diskrepanz in den Daten.
Würde ein manuelles pull die Daten wieder angleichen?

Gruß Ottoderxte

Tode:
Dann hättest Du für so lange eine Diskrepanz, bis Du die Replizierprotokolle auf allen Datenbanken gelöscht hättest... ohne ein Tool wie "Ytria Replication EZ" wird das SEHR VIEL Arbeit...

Denn: Der Clusterpartner ist ja der Meinung, er hätte gerade eben zuletzt repliziert... Alles was älter ist, als der letzte dokumentierte Replizierzeitpunkt im Replikationslog wird ignoriert und nicht erneut repliziert... es sei denn, Du löschst das Gedächtnis: Dann gleicht der Server nochmal alles ab...

CarstenH:
[TLDR] Kurzfassung: Dauerhaft verloren ist alles, was zuvor weder Replikator noch Transaktionsprotokoll woanders gespeichert haben/hatten. [/TLDR]

Zwei Dinge möchte ich noch zu Torstens Ausführungen ergänzen:

Die Systemzeit des zurückgesetzten Systems sollte bei ausgeschaltetem Domino sofort erst einmal aktualisiert werden bevor man anfängt da irgendetwas zu löten!

Eine dauerhafte 2-h-Lücke wird man dann (vermutlich) hinterher an all den Stellen haben, die nicht zu den geclusterten Daten gehören (primär sind das i.d.R. alle Arten von Server-, Datenbank- und Aktivitätslog's). "Vermutlich" deshalb, weil man es ohne Blick auf die Konfiguration gar nicht pauschal sagen kann, viel zu viele Details hängen von der tatsächlichen Umgebung ab, insbesondere Speicherort und und -Art der Transaktionslogs (TXL) und ob der virtuelle Datenträger ebenfalls dem Rollback unterliegt. Sollte das nicht der Fall sein ist ein Replay auch auf nicht geclusterte Daten möglich, sofern diese nicht vom TXL ausgeschlossen wurden.

Zur Replikation an sich noch die Ergänzung, dass es zwei Arten von Replikatoren auf einem solchen System gibt:
1. Clusterreplikator (ereignisgesteuert): jedes Update eines Dokuments einer geclustertern DB wandert in eine Warteschlange, diese wird einfach sequentiell zu allen Clusterpartnern gepusht (solange sie online sind und egal ob diese die Daten tatsächlich brauchen oder nicht solange eine aktive Replik auf dem Ziel existiert), Wiederholungen sind nicht möglich da alle erfolgreich gepushten Daten aus der Queue verschwinden.
2. Normaler Replikator (zeitgesteuert): der normale Replikator "merkt" sich die letzte erfolgreiche Replikation je DB/Zielserver als Zeitpunkt in einem Replikationsprotokoll innerhalb jeder Replik und repliziert nur Änderungen, die danach stattgefunden haben. Deshalb ist es wichtig, bei Problemen dieses Log in der Replik zurückzusetzen (löschen), deren Replikatortask den Vorgang durchführt. Und da der Zeitpunkt im Log vermerkt und unter bestimmten Bedingungen sogar als Entscheidungskriterium bei potentiellen Konflikten herangezogen wird müssen auch die Uhrzeiten der beteilgten Systeme halbwegs korrekt sein.

HTH
Carsten

Ottoderxte:
Ich habe es befürchtet.
Danke für die ausführlichen Antworten.

smokyly:
Jetzt muss ich doch noch mal nachfragen:

Genau das haben wir diese Woche gemacht. Snapshot gezogen, am Slave Update eingespielt, hochgefahren, Cluster Replikation und "normale Replikation" ist angelaufen, dann sind wir wieder zurück auf den Snapshot.
Das bedeutet, dass wir jetzt Inkonsistenzen haben. Ist nicht schlimm, ich lege dann einfach bei Bedarf im Slave wieder neue Repliken an.

Abär - wäre diese Vorgehensweise richtig gewesen?:

- Cluster Replikation abschalten
- zusätzliche Replikation abschalten
- Snapshot ziehen
- werkeln
- wenn es in die Hose geht, Snapshot zurück spielen
- wenn es dann irgendwann läuft beide Replikationen wieder aktivieren

Navigation

[0] Themen-Index

[#] Nächste Seite