PLANNING
Cluster replication is event-driven, rather than schedule-driven. When the Cluster Replicator learns of a change to a database, it immediately pushes that change to other replicas in the cluster. If there is a backlog of replication events, the Cluster Replicator stores these in memory until it can push them to the other cluster servers. If a change to the same database occurs before a previous change has been sent, the Cluster Replicator pools these changes and sends them together to save processing time.
Because HCL Domino® stores replication events in memory only, both the source and destination servers must be available for the replication to complete successfully. If a destination server is not available, the Cluster Replicator continues to store the events in memory until the destination server becomes available. The Cluster Replicator attempts periodically to push these replication events to the destination server. The interval between these attempts starts at one hour and increases over time to a maximum of one day.
If the source server shuts down before the replication completes, the replication events in memory are lost. For this reason, you should use standard replication (the REPLICA task) to force immediate replication with all members of the cluster whenever you restart a cluster server. It is also a good idea to schedule replication between cluster servers on a regular basis, such as several times per day, to ensure that databases remain synchronized.
When the Cluster Replicator logs replication events to the log file, any replication events that are awaiting a retry are also recorded. This lets you see which databases are not currently synchronized and see what errors are preventing replication. After the errors are corrected and successful replication is completed, the error information is no longer recorded.
The Cluster Replicator leaves the processing of replication formulas to the standard replicator. Because these formulas can use a lot of processing power, they are not processed by the Cluster Replicator in order to minimize the overhead of using cluster replication. If you use selective replication, therefore, a database may temporarily include documents that do not match the selection formula. Domino deletes these documents when you run standard replication.
Note: The Cluster Replicator disregards the Space Saver setting Receive summary and 40KB of rich text only.
Note: Standard replication cannot automatically remove changes to specific database elements, such as the ACL, agents, or design elements. If limiting the replication of these items is important for a database, consider using only standard replication, not cluster replication, with that database.
Replication history in a cluster
Because replication events occur so frequently in a cluster, the Cluster Replicator does not read from or write to the replication history of a database each time it replicates the database. When replication is successful, the history information is stored in memory. Each subsequent successful replication event adds to the history information kept in memory. The Cluster Replicator transfers the history information to the databases approximately once an hour.
Private folder replication in a cluster
During standard replication, private folders and their contents do not replicate, except when replicating with the client of the folder owner. Within clusters, however, private folders do replicate to other replicas within the cluster. This behavior ensures that when clients fail over, no matter which replica they access, the database contents are identical. Both cluster replication and standard replication support replicating private folders and their contents within a cluster.
Private folders can be accessed only by the creator of the folder or a server within the cluster. Only servers defined as user type "server" or "server group" in the access control list (ACL) can access and replicate private folders within a database. Servers that are not explicitly included in the ACL cannot replicate private folders.
Parent topic: How Domino clustering works
Related concepts Forcing immediate replication The database replication history Planning a cluster Setting up a cluster
Related tasks Scheduling server-to-server replication