Replikation - replication is disabled

[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]

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

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

[Tode]

Und hoffentlich gibt es keine „Nicht- Mail- Datenbanken“ mit unsauber gepflegten Leserfeldern.... aber auch das wurde sicher im Vorfeld gecheckt...

[eknori]

Klar kann man das mit Tools machen. Die hat nur nicht jeder.

[Tode]

Schon klar, deshalb das Augenzwinkern. Ich habe natürlich den Code zum „manuellen“ Vergleich auch rumliegen, also geht es such gut ohne Tools.

[Lisa]

Guten Morgen ihr beiden,
wenn ich die Dateien abgleiche, fehlen von einer Ausnahme abgesehen einmal 50 und einmal 80 Maildateien am Block bei Sortierung nach Titel (Vorname), für die kein Mailrumpf vorhanden ist. Keine Veränderung in der Anzahl der Dateien seit gestern.
Danke für Eure Tipps, die ich jetzt erstmal abarbeite!

Und hoffentlich gibt es keine „Nicht- Mail- Datenbanken“ mit unsauber gepflegten Leserfeldern.... aber auch das wurde sicher im Vorfeld gecheckt...

Ich vermute, dass Leserfelder diejenigen in einer Anwendung sind, die nicht per Maske eingegeben sondern zur Laufzeit berechnet werden? Keine Ahnung, was mit "unsauber gepflegt" gemeint ist.

Gruß Lisa

P.S.
Der Dienstleister ist ok und im Urlaub und meine Aufgabe ist es, die Hindernisse aus dem Weg zu räumen und zu prüfen, ob das System für das „Umlegen des Schalters“ bereit ist. Unser Mailsystem ist 1999 aufgesetzt worden und ich kam sechs Jahre später dazu. Der Chef hat entschieden, dass der DL das System komplett neu aufsetzt und konfiguriert, um möglichst viele „Altlasten“ zu beseitigen.
Ich bin froh, in Notes Erfahrungen sammeln zu können. Sonst ist es wie bei MSSQL. Ich bin Administrator und das System läuft nahezu fehlerfrei seit 2011. Wenn wirklich mal ein schwerwiegender Fehler auftreten sollte, sind die Schulungen lange her…

[Tode]

Nun "unsaubere" Leserfelder bedeutet: Es nicht in mindestens einem Leserfeld die Gruppe "LocalDomainServers" oder eine generische Rolle vorhanden, die per ACL den Servern zugewiesen werden können. Dadurch werden diese Dokumente bei einer Server - Server- Replikation unter Umständen nicht mitrepliziert.

Zur anderen Frage: Wenn Du über den Admin- Client Repliken erstellen lässt, dann werden dafür Admin- Anforderungen in der admin4.nsf erstellt. Und wenn da was nicht klappt, dann siehst Du den Fehler in der admin4.nsf...

[Lisa]

Guten Morgen,
als ich nach Abgleich aller Maildatenbanken mit den Vaulteinträgen  wegen des Fehlens einer ID am Client einen manuellen Abgleich machen wollte, war dieser Punkt ausgegraut??

Es werden immer noch einige MailDBs nicht repliziert.
Ich korrigierte  ACLs, deren LocalDomainservers keine Dokumente löschen und/oder replizieren durften.
In zwei Fällen hatten Otherdomainservers keine Rechte zum Replizieren. Eigentlich ist das alles dieselbe Domäne und doch verhinderte dieses fehlende Recht bereits kürzlich eine erfolgreiche Replikation. Bei einer Datenbank ist das Setzen dieses Hakens ist ausgegraut??

Zwei Benutzer haben eine Replizier- und Speicherkonflikt seit einem Jahr. Damals wurde ein Server abgeschaltet. Ob dies eine Behinderung darstellt, weiß ich nicht

Bei den anderen DBs finde ich keinen Grund. Fehlermeldungen finde ich keine.

Wegen adminp: ich hoffe, der Dienstleister hat ADMINP_EXCHANGE_ALL_UNREAD_MARKS gesetzt und auf allen Datenbanken sichergestellt, dass Ungelesen- Markierungen repliziert werden

Ich würde die DBs versuchen, manuell zu replizieren, weiß jedoch nicht, wo und wie ich die Einstellungen für die Ungelesenmarkierungen setzen muss??

Gruß Lisa

[Pfefferminz-T]

Ungelesenen Markierungen steht wirklich alles in der Admin-Hilfe-Datenbank drin:

hilfe auf, unread marks ->
Creating replicas in a cluster
replicating unread marks

Und wenn man "unread marks" bei Google reinwirft, dann kommen noch ein paar Technotes dazu.

Das ist Basic-Wissen und ich bin mehr als verwundert, dass euer  Dienstleister diese wichtigen Punkte nicht mit euch am System anschaut.

OtherDomainServers bedeutet Server einer anderen Domäne. Außer ihr habt dort Server eingetragen, die ihr nicht in den LocalDomainServers habt. LocalDomainServers muss auch nicht zwingend in einer ACL stehen, die meisten Unternehmen verwenden nicht die Standardgruppen sondern haben eigene Servergruppen um den Zugriff gezielter zu steuern.

[Lisa]

Guten Tag,

die Umstellung auf Notes 9 ist kürzlich erfolgt und im Großen und Ganzen recht reibungslos verlaufen.
- die Ungelesenmarkierungen wurden bei einigen Repliken nicht korrekt übertragen
- vereinzelt sind gelöschte Dokumente in der Replik wieder aufgetaucht
Weniger schön ist,
- dass die 853er ID-Vault-Datei mit dem 9er Server nicht kooperieren will.
- Certifier becomes inactiv; unklar ist, wann dies passiert.
- eine Anwendung bringt Fehler im Log, funktioniert aber erstmal.

Lisa




 

[Lisa]

Alles funktioniert nun.
Vault ist übertragen, certlog.nsf neu angelegt.

Eine Fehlermeldung beim Zugriff auf die Entwürfe ließ sich im Designer beheben:
https://atnotes.de/index.php?topic=58424.0

Durch Wechseln der Schablone ließen sich die in einigen Datenbanken gelöschten aber in der Replik wieder aufgetauchten Dokumente bereinigen.

Lisa