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.

Replication, step-by-step

To fully understand replication, you need to be familiar with the information in the topics "Guidelines for setting server access to databases" and with "Setting up a database ACL for server-to-server replication" in this chapter. You also need to fully familiarize yourself with the information on replication in the appendix "Server Commands."

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 IBM® Lotus® 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.

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.

• 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.

• 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.

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

Related topics

Creating a LAN connection
Replicas
How a server connects to another server
Replicate
Running server tasks

Glossary