How replication works behind the scenes
This topic describes pull-push replication, which is the default type of replication.
In the following example, the Replicator on Server A replicates between Server A and Server B. To do this, the Replicator on Server A uses Notes RPC capabilities to read from and write to replicas on both servers. No Replicator runs on Server B.
The example refers to a “source” replica and a “destination” replica. When Server A pulls from Server B, the source replica resides on Server B, and the destination replica resides on Server A. When Server A pushes to Server B, the source replica resides on Server A, and the destination replica resides on Server B.
The Replicator task remains idle until the server initiates replication. Then the following occurs:
1. When a server initiates replication with another server, the servers authenticate each other by finding a certificate in common and testing to be sure the certificates are authentic.
2. The Replicator on the initiating server (Server A) searches the directory of databases on both servers and constructs a list of the databases on each server.
3. The Replicator searches through the two lists to find databases that have identical replica IDs. A replica ID is an 8-byte number that Notes creates when it creates a database. The number represents the day and time that the database was created. Databases that are replicas have the same replica ID.
4. When the Replicator finds a match, it looks at the replication history in the source replica to find the last time the replicas replicated.
5. The Replicator searches the source replica for notes that have changed since the last replication. To find this information, the Replicator issues an NSFSearch request against the source replica. To receive the correct documents, the Replicator passes NSFSearch the time from the replication history of the source replica, as well as any replication settings or replication formulas that are in the destination replica. NSFSearch returns several pieces of information, including a list of the OIDs of all documents
that have been created or modified since the last replication, as long as they meet the criteria of the replication settings and replication formula. (If there are no entries in the replication history, Note An OID consists of three parts: a UNID, which is a unique 16-byte document identifier that never changes; a sequence number, which indicates how many times the document has
been modified; and a time stamp, which indicates the last time the document was modified. Each of these parts plays a role in replication.
6. The Replicator issues another NSFSearch request, using the UNIDs in the list it received from the source replica to search the destination replica for the corresponding notes. It receives information, including a list of the OIDs, of the corresponding notes.
7. The Replicator examines the two lists of OIDs to determine what to replicate and where conflicts exist. If the UNID of a note in the source replica does not have a corresponding UNID in the destination replica, this is a new note. The Replicator pulls that note to the destination replica. If a note in the source replica has the same OID as a note in the destination replica, the notes
are identical; no replication is necessary. For notes that have the same UNID but different OIDs, the Replicator checks the revision histories of the notes (the $Revisions field) to determine if a conflict exists. The revision history is a list of when changes were made to a note. Each time someone updates a note, the time from the OID is transferred to the revision history, and the current time is placed in the OID. During replication, the $Revisions field is updated so that the revision history in
corresponding notes is identical.
Here are the rules the Replicator follows to determine if there is a conflict:
If the revision histories are identical except that one has additional entries, no conflict exists. This shows that one note has information that can be replicated to the other note. If the changed note is in the source replica, the changes are pulled to the destination replica. If the revision histories are identical to a point but then both have additional entries, both have changed and a conflict exists.
8. If a conflict exists, the Replicator checks the field $ConflictAction in the destination document. If this field contains a “1,” the Replicator can copy the changes from the source document to the destination document (merge the documents) if the changes in the documents are in different fields. Otherwise, the Replicator must create a conflict document.
A “1” in the $ConflictAction field indicates that the form for the document was designed with “Merge Replication Conflicts” enabled or that the field was set with an API program, LotusScript, or Java.
9. If $ConflictAction=1 in the destination document, the Replicator uses the following logic to determine if the changes to the documents are in different fields: The Replicator looks at the sequence number in the corresponding field of each document
and compares the numbers to the sequence number that existed in the note when the divergence began in the revision history. This determines whether the field changed since the point of divergence. If both fields changed since the point of divergence, there is a conflict and you cannot merge the documents. If only the source field changed since the point of divergence, you can pull that field to the destination document. The Replicator copies changes from one document to another only if it can do so in all the fields that have changed. Otherwise, it creates a conflict document.
10. If there is a conflict and the Replicator cannot merge the documents, it leaves one of the documents as it is (the “winner”) and turns the other documents into a conflict document (the “loser”). The Replicator uses the following logic to determine a winner and a loser: The note that has the highest sequence number in its OID is the winner. If the sequence numbers are the same, the note that has the most recent time stamp in its OID is the winner. The losing server always creates the conflict document. While doing a pull, if the losing server is the destination server, it pulls the winner from the source server and then creates a conflict
document as a response to the winner. If the losing server is the source server, no conflict document is created during a pull because the source server cannot pull the winner from the destination server. In this case, the conflict document is created during the push portion of replication.
12. The Replicator on Server A initiates the push portion of replication. The Replicator on Server A still does all the work, but the replica on Server A is the source replica and the replica on Server B is the destination replica
This topic describes pull-push replication, which is the default type of replication.
In the following example, the Replicator on Server A replicates between Server A and Server B. To do this, the Replicator on Server A uses Notes RPC capabilities to read from and write to replicas on both servers. No Replicator runs on Server B.
The example refers to a “source” replica and a “destination” replica. When Server A pulls from Server B, the source replica resides on Server B, and the destination replica resides on Server A. When Server A pushes to Server B, the source replica resides on Server A, and the destination replica resides on Server B.
The Replicator task remains idle until the server initiates replication. Then the following occurs:
1. When a server initiates replication with another server, the servers authenticate each other by finding a certificate in common and testing to be sure the certificates are authentic.
2. The Replicator on the initiating server (Server A) searches the directory of databases on both servers and constructs a list of the databases on each server.
3. The Replicator searches through the two lists to find databases that have identical replica IDs. A replica ID is an 8-byte number that Notes creates when it creates a database. The number represents the day and time that the database was created. Databases that are replicas have the same replica ID.
4. When the Replicator finds a match, it looks at the replication history in the source replica to find the last time the replicas replicated.
5. The Replicator searches the source replica for notes that have changed since the last replication. To find this information, the Replicator issues an NSFSearch request against the source replica. To receive the correct documents, the Replicator passes NSFSearch the time from the replication history of the source replica, as well as any replication settings or replication formulas that are in the destination replica. NSFSearch returns several pieces of information, including a list of the OIDs of all documents
that have been created or modified since the last replication, as long as they meet the criteria of the replication settings and replication formula. (If there are no entries in the replication history, Note An OID consists of three parts: a UNID, which is a unique 16-byte document identifier that never changes; a sequence number, which indicates how many times the document has
been modified; and a time stamp, which indicates the last time the document was modified. Each of these parts plays a role in replication.
6. The Replicator issues another NSFSearch request, using the UNIDs in the list it received from the source replica to search the destination replica for the corresponding notes. It receives information, including a list of the OIDs, of the corresponding notes.
7. The Replicator examines the two lists of OIDs to determine what to replicate and where conflicts exist. If the UNID of a note in the source replica does not have a corresponding UNID in the destination replica, this is a new note. The Replicator pulls that note to the destination replica. If a note in the source replica has the same OID as a note in the destination replica, the notes
are identical; no replication is necessary. For notes that have the same UNID but different OIDs, the Replicator checks the revision histories of the notes (the $Revisions field) to determine if a conflict exists. The revision history is a list of when changes were made to a note. Each time someone updates a note, the time from the OID is transferred to the revision history, and the current time is placed in the OID. During replication, the $Revisions field is updated so that the revision history in
corresponding notes is identical.
Here are the rules the Replicator follows to determine if there is a conflict:
If the revision histories are identical except that one has additional entries, no conflict exists. This shows that one note has information that can be replicated to the other note. If the changed note is in the source replica, the changes are pulled to the destination replica. If the revision histories are identical to a point but then both have additional entries, both have changed and a conflict exists.
8. If a conflict exists, the Replicator checks the field $ConflictAction in the destination document. If this field contains a “1,” the Replicator can copy the changes from the source document to the destination document (merge the documents) if the changes in the documents are in different fields. Otherwise, the Replicator must create a conflict document.
A “1” in the $ConflictAction field indicates that the form for the document was designed with “Merge Replication Conflicts” enabled or that the field was set with an API program, LotusScript, or Java.
9. If $ConflictAction=1 in the destination document, the Replicator uses the following logic to determine if the changes to the documents are in different fields: The Replicator looks at the sequence number in the corresponding field of each document
and compares the numbers to the sequence number that existed in the note when the divergence began in the revision history. This determines whether the field changed since the point of divergence. If both fields changed since the point of divergence, there is a conflict and you cannot merge the documents. If only the source field changed since the point of divergence, you can pull that field to the destination document. The Replicator copies changes from one document to another only if it can do so in all the fields that have changed. Otherwise, it creates a conflict document.
10. If there is a conflict and the Replicator cannot merge the documents, it leaves one of the documents as it is (the “winner”) and turns the other documents into a conflict document (the “loser”). The Replicator uses the following logic to determine a winner and a loser: The note that has the highest sequence number in its OID is the winner. If the sequence numbers are the same, the note that has the most recent time stamp in its OID is the winner. The losing server always creates the conflict document. While doing a pull, if the losing server is the destination server, it pulls the winner from the source server and then creates a conflict
document as a response to the winner. If the losing server is the source server, no conflict document is created during a pull because the source server cannot pull the winner from the destination server. In this case, the conflict document is created during the push portion of replication.
12. The Replicator on Server A initiates the push portion of replication. The Replicator on Server A still does all the work, but the replica on Server A is the source replica and the replica on Server B is the destination replica