Clusterreplikation in 8.5.2 Cluster: Einzelne Felder werden nicht repliziert

[Tode]

Ich habe hier mal wieder ein tolles Problem, das ich mir nicht erklären kann:

1 Datenbank wird im Cluster repliziert, und das tut sie auch erfolgreich: Nummer Dokumente in beiden Repliken ist identisch, Änderungen replizieren sauber, etc.
Die Datenbank hat auf beiden Clustern die Replikation aktiviert, und keine speziellen Optionen in den Replikationsparametern gesetzt, also keine Schweinereien ala feldweise Replikation oder selektive Replikation o.ä.

Trotzdem tut die Datenbank etwas seltsames: Es gibt einzelne Dokumente, die auf beiden Repliken identisch sind (gleiches Änderungsdatum, gleiches Erstelldatum, identische $Revisions- Einträge), aber leider nur FAST:

3 Felder innerhalb dieser Dokumente unterscheiden sich auf beiden Servern: Sie haben jeweils unterschiedliche Inhalte und auch unterschiedliche Seq Num- Werte (teilweise erheblich unterschiedlich: 23 auf einem Server, 44 auf dem anderen).

Aktualisiert man ein Dokument, dann repliziert die Änderung, aber die 3 Felder bleiben wieder unberührt. Erst wenn man die Felder explizit ändert (also ein leerzeichen hinzufügt oder entfernt), dann wird diese Änderung repliziert, und es sind nur noch 2 Felder "out of sync".

Die Felder haben das Summary- Flag gesetzt und sehen auch sonst in den Properties völlig normal aus. Es sind keine erweiterten Eigenschaften (Editor Zugriff nötig, verschlüsseln im Abschnitt o.ä. im Design gesetzt.

Die einzige Merkwürdigkeit in den Dokumenteingeschaften ist: Es gibt einen Abschnitt im Dokument (Standard, nicht mit Zugriffskontrolle).
Dieser Abschnitt heisst "Kopfzeile" und es existiert in diesen Dokumenten ein Feld namens "$Kopfzeile" mit dem Wert "Kopfzeile"... das wäre mir so noch nie bewusst bei anderen Masken aufgefallen.

Irgendwer ne Idee, wo ich da noch nachschauen könnte?

Ach ja: Die Clients sind noch 7.0.3, die Server alle auf 8.5.2

Thanx
Tode

[Mandalor]

Tritt der Fehler wiederholt auf oder ist es ein einmaliges Probelm?

hast du mal versucht die Daten über eine normale Replikation abzugleichen? ev. vorher das Replizierungsprotokoll auf beiden Seiten löschen.

Aus meiner erfahrung lasse ich in einem Cluster immer auch eine periodische Replikation laufen, da der Clusterreplikator die Änderungen nicht immer überträgt (z.B. wenn der eine Server temporär down ist)

[Tode]

Natürlich haben wir manuell schon versucht, den Fehler zu beheben. Aber weder das löschen des Replizierprotokolls noch andere Massnahmen führen zum Erfolg.

Und wie bereits erwähnt: Ändert man ein Feld im Dokument, dann wird diese Änderung übertragen, aber die 3 fehlerhaften Felder sind trotzdem bei beiden Servern unterschiedlich. Erst wenn man explizit eines der betroffenen Felder ändert, repliziert sich die Änderung durch.

Da wir nicht wissen, wann das Problem angefangen hat und auch nicht wissen, iob es eine einmalige Geschichte ist oder etwas was immer wieder passiert, sind wir folgendermassen vorgegangen: Wir haben einen Agenten geschrieben, der die unterschiedlichen Dokumente findet und in einen Ordner schiebt. Es sind ca. 20 von 10.000. Diese Dokumente werden manuell bereinigt und ein nächtlicher Agent wacht darüber, ob das wieder passiert... Wenn das der Fall ist, haben wir mehr Informationen und werden das Problem genauer unter die Lupe nehmen.

Wenn es nicht wieder passiert, dann haken wir es als einmailges Event, verursacht durch die Migration von 7 auf 8.5 ab...

Thanx
Tode 

[ghostmw]

... bingo ...

Wir haben aktuell in einer DB das gleiche / ähnlich gelagerte Problemchen.

2 Server A + B im Cluster  und 2 Server C + D auch im Cluster.
A + B replizieren periodisch mit C + D

Konstellation:
Wir ändern auf einer Seite (Server A) das Richtextfeld (1 Feld namens "Content" m. Anhängen etc.).

Es repliziert wunderbar auf A+B, nur auf C+D kommt das Richtext 2x (2 Felder - eins mit den alten Werten und eins mit den neuen ).
Geöffnet wird beides dargestellt.
Die Index nummern des Feldes sind auf A+B 1 und auf C+D 2 und 3 komischerweise.
Klasse, wenn nach der nächsten Änderung auf C oder D nach der nächsten Replikation A+B auch schrottig sind.

Wir haben bereits einen SPR bei IBM aufgemacht, vielleicht könnt ihr euch da dran hängen.

SPR => GTON8C8C2H

Liebe Grüsse
M. Weller

[Tode]

Aber nicht zufällig bei unserem gemeinsamen Kunden im Schwarzwald, oder? Wenn ich mal im Büro wäre, hätte ich Dich sicherlich auch mal gefragt.

Grüsse aus Freiburg (normalerweise, jetzt gerade in der Schweiz)
Torsten