In der Notes/Domino-Forum von Xing wird ein Problem bei Feldreplikation im Cluster beschrieben. Das möchte ich zum Anlass nehmen, den "Mechanismus" Replikation einmal gründlicher zu beleuchten.

Startet ein Notes-Client oder ein Domino-Server eine Replikation mit einem (anderen) Domino-Server, so wird dort zunächst nach einer Notes-Datenbank mit der gleichen Replik-ID gesucht. Die Replik-ID einer Datenbank findet man im 2. Reiter der Datenbank-Eigenschaften:

Findet der Server eine Replik, dann sucht er im Replizierprotokoll, ob die beiden Datenbanken schon einmal miteinander erfolgreich repliziert wurden. Dieser Protokolleintrag enthält den Zeitpunkt, wann sie das letzte Mal repliziert wurden und sich damit in einem "synchronen" Status befunden haben. Wenn er keinen passenden Eintrag für die beiden Replikationspartner findet, werden auf beiden Seiten die Listen aller Dokumente miteinander verglichen: Für jedes Dokument einer Datenbank wird nach dem entsprechenden Dokument - also nach dem Dokument mit der gleichen Unique ID - gesucht. Gibt es einen passenden Eintrag im Protokoll, wird nur nach Dokumenten gesucht, die nach dem Zeitpunkt der letzten Replikation erstellt, geändert oder gelöscht wurden.

Nach diesem Vergleich gibt es im Prinzip drei Listen:

• Dokumente, die es nur auf der einen Seite gibt,
• Dokumente, die es nur auf der anderen Seite gibt und
• Dokumente, die es auf beiden Seiten gibt.
  
  Gibt es ein Dokument nur auf einer Seite, ist die Sache einfach: Es muss eine Kopie dieses Dokuments auf der jeweils anderen Seite erstellt werden. Komplizierter ist der Fall, wenn ein Dokument auf beiden Seiten existiert. Hierfür hat sich Lotus etwas einfallen lassen:
  
  Jedes Dokument hat eine Sequenznummer. Wird ein Dokument das erste Mal gespeichert, ist die Sequenznummer 1, danach wird sie bei jedem Speichern jeweils um 1 erhöht. Finden kann man die Sequenznummer eines Dokuments auf dem sechsten Reiter der Dokument-Eigenschaften - als Hexadezimalzahl in der dritten Zeile nach dem Bindestrich:
  
  Dieses Dokument wurde also insgesamt 15 mal gespeichert.
  
  Außer den Dokumenten hat auch jedes einzelne Item eine Sequenznummer. Wenn man auf dem zweiten Reiter der Dokument-Eigenschaften links ein Item auswählt, werden rechts die Details dargestellt - darunter auch die Sequenznummer als Dezimalzahl:
  
  
  Wird ein Dokument das erste Mal gespeichert, erhalten es selbst und alle seine Items die Sequenznummer 1. Wird es später bearbeitet und erneut gespeichert, wird die Sequenznummer des Dokuments um 1 erhöht. Außerdem wird für jedes Item geprüft, ob es geändert wurde seit dem letzten Speichern. Falls nicht, wird es nicht verändert, behält also auch seine bisherige Sequenznummer. Hat es sich aber geändert, so bekommt es die aktuelle Nummer des Dokuments als Sequenznummer. Das Bild oben besagt also, dass das Item EntryHTML beim 15. Speichern des Dokuments geändert wurde - und nicht, dass das Item 15 Mal geändert wurde.
  
  Zusätzlich wird in jedem Dokument die Zeitpunkte der Erstellung und der letzten Änderung in einer internen Eigenschaft gespeichert, die man auf dem ersten Reiter der Dokument-Eigenschaften nachsehen kann. Im Item $Revisions wird die Liste der Zeitpunkte gespeichert, wann es geändert wurde, und in $UpdatedBy die Liste der NotesNamen, wer es geändert hat.
  
  Alle diese Angaben zusammen helfen dem Replikator zu bestimmen, wo wann welche Änderungen vorgenommen wurden und ob ein Replikationskonflikt vorliegt. Normalerweise wird dann, wenn ein Dokument seit der letzten Replikation auf beiden Seiten geändert wurde, ein Replikationskonflikt erstellt. Ist in der Maske "Replikationskonflikte mischen" ausgewählt - und hat dadurch das Dokument ein Item $ConflictAction mit dem Wert "1", so wird auf Item- statt Dokumentenebene bestimmt, ob ein Konflikt vorliegt. Der Replikator nutzt die Sequenznummern der Items in beiden Dokumente, um zu bestimmen, welcher Wert in das gemischte Dokument einfließt. Wenn er feststellt, dass das gleiche Item auf beiden Seiten verändert wurde, erstellt er wieder ein Replikationskonflikt. In diesem Fall wird das eine Dokument zum Kind-Dokument des anderen gemacht und bekommt ein Item $Conflict.
  
  Sonderfall: gelöschte Dokumente
  Wird ein Dokument gelöscht, soll es natürlich (im Normalfall) nicht bei der nächsten Replikation wieder - wie ein neu erstelltes Dokument - von der anderen Replik übernommen werden. Damit Notes unterscheiden kann, ob es ein neues oder gelöschtes Dokument ist, wenn der Replikator das Dokument nur in einer Datenbank findet, wird beim Löschen eines Dokuments ein "Deletion Stub" angelegt. Dieser enthält im Wesentlichen die Information, dass es ein Dokument mit einer bestimmten Unique ID gegeben hat und es gelöscht wurde. Findet der Replikator beim Vergleichen der Datenbank-Repliken auf einer Seite einen Deletion Stub, so löscht er das Dokument aus der anderen Replik.
  
  Update:
  Rob Axelrod, Vice-President von Technotics, Inc. hat mich freundlicherweise unterstützt und einige Unklarheiten beseitigt.
  
  Update 2:
  Scheinbar gibt es einen Fehler mit $ConflictAction und der "Repklikationskonflikte mischen"-Einstellung seit der Version 6.5.1. Details und Links zu den entsprechenden Technotes gibt es hier:
  Is IBM Lotus asleep at the wheel? What is up with $ConflictAction???, Lord Lotus Blog