Replication topology

When advanced replication is configured, specific entries in the directory are identified as the roots of replication subtrees or replication contexts by adding the auxiliary objectclass ibm-replicationContext to them. Each of these replication contexts are replicated independently. The subtree continues down through the Directory Information Tree (DIT) until reaching the leaf entries or other replicated subtrees or contexts. Entries are added below the root of the replicated subtree to contain the replication configuration information. There are one or more replica group entries created directly under each replication context. For each replica group entry, there is a corresponding replica subentry that identifies the role the server plays in the replication environment. Associated with each replica subentry are replication agreements that identify the servers that are supplied (replicated to) by each server and defining the credentials and schedule information.

By using advanced replication, a change made to one server is propagated to one or more additional servers. In effect, a change to one server can show up on multiple different LDAP servers. z/OS® IBM® Tivoli® Directory Server supports either basic or advanced replication but not both at the same time. Advanced replication includes:

replication of subtrees of the Directory Information Tree to specific servers
a multitier topology, referred to as cascading replication
assignment of server role (supplier or consumer) by subtree
multiple master servers, referred to as peer to peer replication
gateway servers that replicate across networks

The advantage of replicating by subtrees is that a replica does not need to replicate the entire directory. It can be a replica of a part, or subtree, of the directory.

The advanced replication model changes the concept of master and replica servers. These terms no longer apply to servers, but rather to the roles that a server has regarding a particular replicated subtree. A server can act as a master for some subtrees and as a replica for others. The term, master, is used for a server that accepts client updates for a replicated subtree. The term, replica, is used for a server that only accepts updates from other servers designated as a supplier for the replicated subtree.

The types of directory roles as defined by function are: master-replica, peer-peer, forwarding (cascading), gateway

Table 1. Server roles
Option	Description
Master-replica	A replica is an additional server that contains a copy of the directory information that is replicated from the master server. The replicated data can be the entire DIT or just a portion of the DIT that is replicated to the replica. The replica server provides a read-only backup of the replicated subtree.
Master-peer	The master-peer server contains the master directory information from where updates are propagated to the replicas. All changes are made and occur on the master server, and the master is responsible for propagating these changes to the replicas. There can be several servers acting as masters for directory information, with each master responsible for updating other master servers and replica servers. This is referred to as peer replication. Peer replication can improve performance and reliability. Performance is improved by providing a local server to handle updates in a widely distributed network. Reliability is improved by providing a backup master server ready to take over immediately if the primary master fails. Note: Master servers replicate all client updates, but do not replicate updates received from other masters. Updates among peer servers can be immediate or scheduled.
Forwarding (Cascading)	A forwarding or cascading server is a replica server that replicates all changes sent to it. This contrasts to a master-peer server in that a master-peer server only replicates changes that are made by clients connected to that server. A cascading server can relieve the replication workload from the master servers in a network that contains many widely dispersed replicas.
Gateway	Gateway replication uses gateway servers to collect and distribute replication information effectively across a replicating network. The primary benefit of gateway replication is the reduction of network traffic.

You can request updates on a replica server, but, the update is forwarded to the master server by returning a referral to the client. If the update is successful, the master server then sends the update to the replicas. Until the master has completed replication of the update, the change is not reflected on the replica server where it was originally requested. If replication fails, it is repeated even if the master is restarted. Changes are replicated in the order that they are made on the master. See Recovering from advanced replication errors for more information.

If you are no longer using a replica, you must remove the replication agreement entry from the supplier. Leaving the entry causes the server to queue up all updates and uses unnecessary directory space. Also, the supplier continues trying to contact the missing consumer to try sending the data again. When a replication agreement is deleted, replication is halted immediately. That is, any updates in the replication queue are lost.