Frage an die Profis: Warum DB´s inkonsistent ?

  • Hi Leute,


    bei nem Kunden laufen zwei Domino 5.0.11 Server auf Windows 2993 Systemen. Die Datenbestände der Server sind nahezu identisch, bei sind im Cluster.


    Nun habe ich mehere Datenbanken, die (auch mit deaktiviereten CLuster !!) im Laufe der Zeit inkonsistent werden, d.h. die Anzahl der Dokumente ungleich werden.


    Die ACL´s der Datenbanken sind korrekt gesetzt, das Replizierprotokoll zeigt keine Fehlerheinweise. Ich habe auch keine Chance, die DB´s wieder konsistent zu bringen, Replizierung in ALLE RIchtungen bringen nix.


    Das Löschen des Replizierprotokolls bringt kurzzeitig (!) Besserung, nach wenigen Stunden/Tagen (je nach Häufigkeit der Dokumentänderungen) laufen die DB´s wieder auseinandern.


    Die Replizierparameter sind eigentlich auch okay, so dass ich nicht mehr weiss, wo ich noch ansetzen soll.


    Inzwischen ist Win2003 mein verdächtiger Kandidat, da ja Domino 5.0.11 auch hierfür nicht freigegeben ist.


    Oder hat noch jemand ne anderen Idee ??

  • Tritt der Fehler generell bei allen Datenbanken oder nur bei speziellen selbst, oder von Lieferanten entwickelten auf? Möglicher Weise werden in Dokumenten Leserfelder für die Server gesetzt. ...und stehen die Server explizit in der ACL oder über Gruppen?


    Gruß Enrico

  • Die Datenbanken sind vielfältig, sind alle möglichen.


    Das Problem tritt bei schätzungsweise 100 DB´s unterschiedlichster arten auf (Mail, Doku-DB´s Rundschreiben usw.)


    Leser- und Autorenfelder kann ich ziemlich sicher ausschliessen.

  • Zitat


    Muerte schrieb:
    das cut off date hast du sicherlich auch beachtet oder?


    Ja, habe ich rausgenommen - hat aber nur temporär was gebracht... :(

  • Die Anzahl der DOkumente ist ungleich.... Löschungen werden scheinbar repliziert , neue und veränderte Dokumente nicht.


    Das führt je nach Änderungsaufkommen dazu, dass die DB´s um mehrer 100 Dokumente auseinandern driften.

  • hast du trotz cluster noch replikationsverbindungsdokumente erstellt? vielleicht verschluckt der der cluster replikator etwas...wie sieht die leitung zwischen den servern aus?


    wenn das auch nicht weiterhilft bin ich am ende ;)

  • Du schreibt die acl's sind korrekt gesetzt... aber was dürfen die server gegenseitig dann machen ?
    Dazu hast du den lösch intervall der beide replieken schon mal kontrolliert ?


    Noch einene alternative (der mir schon mal den lösung gebracht hat), schon mal einen neuen repliek der DB auf den andere server gemacht (also der der am meisten die größte menge an dokumente hat) ?


    Ich habe solche problemen schon merhfach gehabt, und teilweise lag es am fehlerhafte acl's (zu wenig rechte) und teilweise als blödheit der programmierer (lesernamen felder in den dokumente, ohne das die server die dokumente gegenseitig sehen dürften).
    Dort hat das problem dann NUR mittels einen design änderung zum endgültigen lösung geführt.. und einen agent der manuell die bestehenden dokumente angepasst hat.
    Um dieses letztes feststellen zu können muß mann dokumente vergleichen (feldweise) und dann versuchen heraus zu finden warum das eine da ist, und das andere nicht.
    Denk dran das der CLUSTER replicator lesernamen ignoriert, aber der "richtige" replicator nicht. Der ENTFERNT dokumente wo der server kein recht drauf hat (also ohne löschrumpf). Diese information ist den meiste Admins NICHT bekannt.

  • Zitat


    BANXX schrieb:
    Hi Leute,


    bei nem Kunden laufen zwei Domino 5.0.11 Server auf Windows 2993 Systemen. Die Datenbestände der Server sind nahezu identisch, bei sind im Cluster.


    Windows 2993 ??? Prima - kannst Du mir das kopieren :lol:



    Zitat


    BANXX schrieb:


    Das Löschen des Replizierprotokolls bringt kurzzeitig (!) Besserung, nach wenigen Stunden/Tagen (je nach Häufigkeit der Dokumentänderungen) laufen die DB´s wieder auseinandern.


    Läßt Du nach dem Löschen des Replizierprotokolls den Server replizieren oder machst Du es als Person? Bei der ersten Variante sind ACL-Probleme eher auszuschließen.


    Hast Du die Uhrzeiten der Server einmal überprüft. Gewisse Dominoversionen hatten mit gewissen Boards (ASUS ???) das Problem, daß sie in undefinierten Abständen die Serverzeit verstellt haben und die DBs so einen Timestamp weit in der Zukunft hatten (unter Eigenschaften DB), was bei uns zu genau den beschriebenen Problemen geführt hat.
    Außerdem waren einige IDs im Jahr 2029 nicht mehr gültig :lol: :lol: :lol:

    Für jedes Problem gibt es eine einfache Lösung, die es noch schlimmer macht.

  • Zitat


    lodsnods schrieb:
    Läßt Du nach dem Löschen des Replizierprotokolls den Server replizieren oder machst Du es als Person? Bei der ersten Variante sind ACL-Probleme eher auszuschließen.


    Hast Du die Uhrzeiten der Server einmal überprüft. Gewisse Dominoversionen hatten mit gewissen Boards (ASUS ???) das Problem, daß sie in undefinierten Abständen die Serverzeit verstellt haben und die DBs so einen Timestamp weit in der Zukunft hatten (unter Eigenschaften DB), was bei uns zu genau den beschriebenen Problemen geführt hat.
    Außerdem waren einige IDs im Jahr 2029 nicht mehr gültig :lol: :lol: :lol:


    Replikation idR per Hand über die Serverkonsole. Teitunterschiede kann ich auch ausschliessen, beide Server holen sich die Zeit von nem NTP-Server.


    Zitat


    Muerte schrieb:
    hast du trotz cluster noch replikationsverbindungsdokumente erstellt? vielleicht verschluckt der der cluster replikator etwas...wie sieht die leitung zwischen den servern aus?


    wenn das auch nicht weiterhilft bin ich am ende ;)


    Vergiss den Cluster erstmal - der funktioniert eigentlich prima. Die DB´s laufen aber sowohl im Cluster als auch ohne auseinander.


    Verbindungsdokumente sind IMO trotz Cluster ein MUSS - wie willst Du sonst DB´s, die nicht im Cluster sind abgleichen ? Und alles cluster ist nur unnötig BElastung für den Cluster.


    Danke für deine Tips :D



    ACL´s sind die Server jeweils Manager mit Löschrechten und allen evtl. vorhandenen Rollen. Habe sowohl mit EInzelrechte, Gruppenrechten und den Benutzertypen experimentiert - alles ohne zählbaren Erfolg.


    Da es sich um verschiedenste DBs handelt (einfach Rundschreiben-DB´s, Adressbücher und Mail-DB´s kann ich mir nicht vorstellen, dass Leserfelder in ALLEN DB´s auftauchen.


    Ich kann das Problem wunderbar in einer bestimmten DB jederzeit nachstellen.


    Die DB dient als Personencontainer und hat einen periodischen Agenten, der täglich alle Dokumente aus der DB löscht und aus einer zweiten DB in die COntainer-DB kopiert (wozu diese DB auch immer dient - ist aber auch egal in diesem Fall). Wenn die DB auf beiden Servern identisch ist, der Agent läuft und nach dem Agentenlauf repliziert wird, ist die DB inkonsistent. Die Löschungen werden repliziert, aber von den neu importierten Dokumenten nur ein Teil (!), der immer unterschiedlichen gross ist (!) auf den zweiten Server repliziert.



    Ich schaffs einfach nicht, einen gemeinsamen Nenner zu finden, der den Fehler jederzeit identisch reproduziert bzw. nen Weg zu finden, wie die DB´s dauerhaft konsistent bleiben.


    Über alle DB´s laufen übrigens auch regelmäßig FIXUP -F, COMPACT -B -S5 und UPDALL -R

  • Hi BANXX,


    da gehen mir auch langsam die Ideen aus.


    Laß den Server doch mal nach dem Löschen der Replikationsprotokolle alleine replizieren, ohne manuell einzugreifen und schau dann mal ins Replizierprotokoll.


    Ansonsten fallen mir nur noch folgende Sachen ein:


    - ist im Verbindungsdokument ein Zeitlimit eingetragen (wäre aber zu einfach :lol:
    - diverse notes.ini Einträge wie REPLICATORS, REPL_ERROR_TOLERANCE, DISABLE_CLUSTER_REPLICATOR ...

    Für jedes Problem gibt es eine einfache Lösung, die es noch schlimmer macht.

  • Hi,


    noch ein kleiner Nachtrag zu den notes.ini Einträgen:


    LOG_REPLICATION


    Die Einstellung 'Replizierung protokollieren' bestimmt die Protokollierungsebene für alle Repliziervorgänge, die vom aktuellen Server ausgeführt werden. Es gibt insgesamt 5 Ebenen, die Sie wählen können:
    1 - Protokolliert, dass eine Datenbank repliziert wird
    2 - Protokolliert zusammenfassende Informationen für jede Datenbank
    3 - Protokolliert Informationen über Dokumente
    4 - Protokolliert Informationen über jedes replizierte Feld
    5 - Protokolliert Informationen über Komprimierung


    Vielleicht kommt man ja so dem Fehler auf die Spur.

    Für jedes Problem gibt es eine einfache Lösung, die es noch schlimmer macht.