IBM Domino Administrator 9.0.1 Social Edition Help

CONFIGURING

How replication works
For server-to-server or server to/from client replication, the Replicator on one computer calls another Domino® server at scheduled times. By default, the Replicator is loaded at startup. To schedule replication between servers, the servers must be able to connect to each other in order to update replicas. You may need to create Connection documents to enable server connections, depending on your server topology.

As users add, edit, and delete documents in a database, the replicas contain slightly different information until the next time the servers replicate. Because replication transfers only changes to a database, the network traffic, server time, and connection costs are kept to a minimum.

During scheduled replication, by default, the initiating server first pulls changes from the destination server and then pushes changes to the destination server. As an alternative, you can schedule replication so that the initiating server and destination server each pull changes or so that the initiating server pulls changes only or pushes changes only.

You can also use the server commands Pull, Push, and Replicate to initiate replication between servers.

To fully understand replication, you need to be familiar with the information in the topics Guidelines for setting server access to databases and Setting up a database ACL for server-to-server replication in the related links.

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 Pull, Push, Replicate, 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, 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 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.

See the related topics for information on server console replication commands and on the Program document.

Feedback on Help or Product Usability?

Help on Help

All Help Contents

Feedback on Help or Usability?

Help on Help

All Help Contents