Domino 9 und frühere Versionen > ND8: Administration & Userprobleme

Replikation - replication is disabled

(1/3) > >>

Lisa:
Guten Tag,
für die Serverumstellung von Notes 8.5.3 auf Version 9 ist ein Dienstleister beauftragt, der u.a. die Datenbanken mittel Replikation auf den neuen Server überträgt.
Für die eigentliche Umstellung soll der alte Server nach Feierabend heruntergefahren und der neue mit dem Servernamen des alten gestartet werden, sodass die Anwender, wenn alles glatt geht, weitgehend gar nichts merken.

Drei der ca. 600 Datenbanken verweigern die Replikation.
replication is disabled for xxx/yyy.nsf bzw. replication is disabled for Zielserver1 xxx/yyy.nsf

Ich finde nur dies:
https://atnotes.de/index.php/topic,44572.0.html von 2009 und https://atnotes.de/index.php/topic,49352.0.html von 2010
probiert habe ich
load compact -c, fixup, updall –r, object collect –force und damit die Datenbanken auf das aktuelle Dateiformat gebracht, so es noch nicht vorlag.
ACL überprüft, Replizierungsoptionen der Datenbank überprüft. Das Replizieren ist nicht disabled. In den Optionen finde ich keine Einstellungen, die nicht auch bei erfolgreich replizierten Datenbanken existieren. Bei einer der DB war DAOS aktiviert obwohl es in den Optionen mit dem alten Dateiformat nicht angezeigt werden konnte. Auf dem Server ist DAOS nicht aktiviert.

Mit einer der Datenbanken kann ich umfangreicher testen. Eine lokale Replik lässt sich erzeugen. Das Replizierprotokoll der Datenbank ist leer. Bei der 2. DB gab es vor Jahren Repliken auf externen Servern.

Ich bin jetzt mit meinem Latein am Ende.
Was kann ich noch überprüfen?

Gruß Lisa

Tode:
[off topic]Hmmm. verstehe ich das richtig: Du hast einen Dienstleister beauftragt, etwas zu tun... Und weil er es nicht hinbekommt, suchst Du hier im Forum nach der Lösung... *g*[/off topic]

So nun zurück: Was passiert denn, wenn Du die Datenbank über Deinen Client manuell replizierst? Also: Kachel öffnen, und dann über das Repliziermenu mit dem anderen Server replizieren?

Stehen beide Server korrekt in der ACL, was sagt der "Effektive Zugriff" auf die Datenbank für die beiden Server?

Dann habe ich per Suche etwas gefunden: Es gibt wohl auch ein "verstecktes" Replication disabled- flag, das man nur mittels API auslesen kann, siehe diesen Link bei IBM. Bei der Suche mit dem Suchbegriff aus diesem Artikel (REPLFLG_NEVER_REPLICATE) bin ich dann auf einen Artikel hier im Forum gestossen zu diesem Flag... Daraus müsste man fertigen Code bauen können, um das Flag auszulesen / zu setzen.

Möglicherweise gibt es hier bei eknori sogar den fertigen Code, auf die Seite komme ich aber hier aus dem Netz nicht drauf, der Proxy meint, das wäre "forbidden content" (Begründung: Url Klassifizierung 'Blog')

Lisa:
Hallo Torsten, herzlichen Dank für Deine Unterstützung; im Forum gibt es Experten!

In die MailDB meines Testanwenders habe ich zwei Agenten mit eknoris Code integriert, laufen lassen und anschließend erfolgreich manuell repliziert.

In der zweiten DB fand ich in den erweiterten Replizieroptionen einen Haken bei Replikation vorübergehend deaktivieren. Geht nun und ich werde demnächst alles selbst überprüfen.

Die dritte DB – MailDB eines Anwenders- war auf dem Zielserver mit knapp 10 % der Größe vorhanden und brachte den disabled-Fehler s.o.
Vor der Mittagspause habe ich das manuelle Replizieren gestartet. Der Fortschrittsbalken lief bis 6% mit der Meldung Änderungen werden gesucht o.ä. Nach der Pause nach wie vor 6% und keine Rückmeldung. Entscheidung für „auf Antwort des Programms warten“. Fertig nach einer weiteren Stunde. In der gut 6 GB großen DB ist DAOS aktiviert.

Auf dem alten Server war kein DAOS aktiv aber dem neuen. Ist das der Grund und ist diese Laufzeit normal?

Heute war ich erstmals auf dem neuen Server. Leider sind ca. 20 % der Maildatenbanken nicht repliziert. Fehlermeldungen find ich keine. Recherche geht weiter.

Hier noch die Links:
https://www.eknori.de/2011-04-24/replication-of-this-database-is-not-permitted/

http://dominopower.com/article/domino-5-0-lotusscript-enhancements-the-notesreplication-class/

Gruß
Lisa

eknori (retired):

--- Zitat ---Auf dem alten Server war kein DAOS aktiv aber dem neuen. Ist das der Grund und ist diese Laufzeit normal?
--- Ende Zitat ---

Bei 6GB und nicht bekannter Server Latenz ist das im Rahmen.

20% der Datenbanken sind nicht repliziert ...

Wofür hatte ihr noch gleich externe Unterstützung?

Sind die Datenbanken als „Rumpf“ bereits auf dem Zielserver vorhanden, oder gar nicht?
Gucke mal in die admin4.nsf. Wenn es richtig gemacht wurde, dann wurde die neue Replik über den Adminp angelegt. Und das kann ein wenig dauern.

Tode:
Darüber mit dem „richtig“ und „über adminp“ kann man jetzt streiten 😜. Mi Ytria ReplicationEZ geht das nämlich auch.. und da kann man dann auch gleich noch schauen, ob die Datenbanken von der Dokumentenanzahl identisch sind und wenn nicht, dann mit ScanEZ die konkreten Unterschiede ermitteln.

Wegen adminp: ich hoffe, der Dienstleister hat ADMINP_EXCHANGE_ALL_UNREAD_MARKS gesetzt und auf allen Datenbanken sichergestellt, dass Ungelesen- Markierungen repliziert werden, denn sonst freuen sich die Benutzer, wenn wahlweise alles, oder alles älter 6 Monate plötzlich ungelesen ist...

Navigation

[0] Themen-Index

[#] Nächste Seite