Skip to content

Lotus Domino Replication – Step-by-Step

Lotus Domino Replication – Step-by-Step

 

1. Replication is initiated by a server or a workstation in one of the following ways:

  • Replication schedule settings in a Connection document take effect.
  • A replication command to replicate immediately is issued at the server console. The server console commands include replicate, pull, push, and load replica.
  • Settings in a Program document. The Program document starts a new task on the server rather than sending work to an existing task.
  • A replication command to replicate immediately is issued by an end-user working in the Notes client user interface. This is done from a workstation only, not from a server.
  • Scheduled replication from a Notes client. This is done from a workstation only.
  • The servers authenticate each other by finding a certificate in common and testing to be sure that certificates are authentic.

 

2. The Replicator constructs a list of local files to replicate and asks the remote server to find those that have a match with the list of local files.

Note: If the server initiating the replication cannot connect to the remote server, or if it cannot search the remote server (Server B), replication fails.

 

3. When the Replicator finds a match, it looks at the replication history to find the last time the replicas replicated. The Replicator uses the history in the local database which is the destination database when “pulling” and is the source database when “pushing.” Typically, there are two such entries, one for each direction (push/pull).

  • If there is no entry in the replication history, if access rights have changed, or if the selective replication settings have changed, the Replicator has to search all documents in the source database, not just those that have changed since the last replication.

 

4. The Replicator searches the source replica for changes that have occurred since the last replication.

  • The Replicator constructs a list of documents in the source database that have changed since the last successful replication. (For a pull, the source is the database on the remote server; for a push, the source is the database on the local server.) The list is restricted by the Selective Replication Settings. The time that the search begins is recorded in the replication history so that succeeding replications do not process changes that have been replicated.
  • If the data in the source database has not changed since the last successful replication to the destination database, no replications take place and the replication history is not updated.

 

5. Replication between the source database and the destination database occurs. Replication history is updated for replication from source database to destination database. If access is sufficient, replication history for both the source and destination databases is updated.

  • If replication is not successful, the replication history is not updated, and the next replication will search the same databases again.

Leave a Reply

%d bloggers like this: