Das Notes Forum
Domino 9 und frühere Versionen => ND8: Administration & Userprobleme => Thema gestartet von: schroederk am 30.03.11 - 11:42:06
-
Hallo,
seit ein Server auf 8.5.2 FP1 aktualisiert wurde, hat sich offenbar die Replic-Einstellung zerschossen.
Ist mir leider nicht sofort aufgefallen.
Kann ich die Replizierung zwischen den beiden names.nsf der beiden Server wiederherstellen?
Mit wäre nur der Weg bekannt, einen Server herunterzufahren und die names.nsf des anderen Servers über das Filesystem zu kopieren (vorher die Replication History löschen)
-
Ein anderer Weg ist mir nicht bekannt.
Ich hatte so einen Fall auch mal und da bin ich genau so vorgegangen wie du es beschrieben hast.
Axel
-
Hmm, das wäre sehr ärgerlich, da ich dann jeden Eintrag kontrollieren muss, bezüglich Änderungen, Neueinträge etc.
Wäre insgesamt sehr praktisch, wenn man Replicas zwischen bestehenden Datenbanken erstellen könnte.
Rein technisch müsste es doch reichen, wenn man bei einer DB einfach die Replik-ID überschreiben könnte, oder?
Vielleicht gibt es ja ein solches Tool?
Hab gerade ein Tool gefunden Antrid (http://www.rprsystems.com/index.html), dass ich mir mal anschauen werde.
-
Hier wäre so ein Toll zu finden:
http://www.turtleweb.com/turtleweb.nsf/otherpageslookup/toolsandtoys?
ich habe es selber auch schon mehrfach eingesetzt.
!!Aber in deinem Falle würde ich das wenn überhaupt erstmal an in einer Testumgebung probieren, damit du nicht alles noch schlimmer machst!!!
-
seit ein Server auf 8.5.2 FP1 aktualisiert wurde, hat sich offenbar die Replic-Einstellung zerschossen.
.... was Du damit meinst, hatte ich nicht verstanden.
Im weiteren Verlauf des Threads stellt es sich so dar, als hätte sich die Replik-ID verändert?!
Das kann ich mir bei einem Update nicht vorstellen. Da scheint etwas anderes passiert zu sein. Haben die Server weiterhin den gleichen Certifier und sind in der gleichen Domäne? Wie sieht das gesamte Konstrukt denn aus? Wenn die Replik-ID nicht mehr stimmt, stimmen vielleicht andere Dinge auch nicht mehr.
Gruß
Wolfgang
-
Ich kann Wolfgang hier nur zustimmen: Da ist etwas oberfaul. Eine ReplicaID ändert sich nicht zufällig oder durch einen "Fehler beim Update". Würde ein Bit kippen (Fehler auf Dateiebene), dann wäre sofort die ganze DB im Eimer (es gäbe schon einen CRC-Fehler auf Filesystem-Ebene, aber auch Notes überwacht die DB mit Prüfsummen!).
Wenn es dann noch eine Weile her ist, dass die beiden DBs als Nicht-Repliken nebenher laufen, dann kann eine Replikation durch Manipulation der ReplicaID absolut unkonstruktiv sein.
Ergo: Wirkliche Ursache ermitteln und dann bestenfalls so vorgehen, wie es Axel hier bestätigt hat. Bei der names.nsf würde ich unter keinen Umständen an der ReplicaID drehen.
HTH,
Bernhard
-
Ich habe mir die Replik-IDs der beiden Datenbanken angeschaut und sie stimmen noch überein.
Auch werden Änderungen und neue Einträge korrekt synchronisiert.
Mir sind nur die Konsolen-Meldungen aufgestoßen:
Unable to replicate with server SERVER/CERT/COMPANY: None of the selected databases has a replica on the server.
-
Und du bist dir sicher, dass es sich um die names.nsf handelt?
Oder kann da noch eine andere Datenbank im Spiel sein?
Axel
-
Was soll denn lt. Verbindungsdokument(en) überhaupt repliziert werden?
Bernhard
-
Unable to replicate with server SERVER/CERT/COMPANY: None of the selected databases has a replica on the server.
Solche Meldungen werden erfahrungsgemäss durch Verbindungsdokumente verursacht, wo Datenbanken aufgeführt sind, die nicht ( mehr ) vorhanden sind.
Gruss,
Joachim
-
Genau darauf wollte ich hinaus, Joachim ;)
Bernhard
-
Laut Verbindungsdokumente (Configuration/Servers/Connections) werden keine Datenbanken gelistet, also alle (all if none specified).
Aufgefallen ist mir jetzt, dass das Verbindungsdokument von Server1 (der die Meldung im Log bringt) zu Server2 disabled ist.
Das Verbindungsdokument von Server2 zu Server1 ist enabled.
Warum sollte das 1. Verbindungsdokument überhaupt deaktiviert sein? Und warum erscheint dann die Fehlermeldung, wenn doch deaktiviert?