Replication topology

You can use the information and example provided here to know more replication topology.

Specific entries in the directory are identified as the roots of replicated subtrees, by adding the ibm-replicationContext objectclass to them. Each subtree is replicated independently. The subtree continues down through the Directory Information Tree (DIT) until reaching the leaf entries or other replicated subtrees (context). Entries are added below the root of the replicated subtree to contain the replication configuration information.These entries are one or more replica group entries, under which are created replica subentries.Associated with each replica subentry are replication agreements that identify the servers that are supplied (replicated to) by each server, as well as defining the credentials and schedule information.

Through replication, a change made to one directory is propagated to one or more additional directories. In effect, a change to one directory shows up on multiple different directories. IBM® Verify Directory supports an expanded master-replica replication model. Replication topologies are expanded to include:

Replication of subtrees of the Directory Information Tree to specific servers
A multi-tier 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 expanded model changes the concept of master and replica. 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.

There are four types of directory roles as defined by function: master/peer, gateway, forwarding (cascading), and replica (read-only).

Table 1. Server roles
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. See Creating replication schedules for more information.
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 clientsconnected to that server. A cascading server can relieve the replication workload from the master servers in a network whichcontains 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.
Replica (read-only)	An additional server that contains a copy of directory information. The replicas are copies of the master (or the subtree that it is a replica of).The replica provides a backup of the replicated subtree.

You can request updates on a replica server, but the update is actually 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 the replication fails, it is repeated even if the master is restarted. Changes are replicated in the order in which they are made on the master. See Replication error handling.

If you are no longer using a replica, you must remove the replica agreement from the supplier.Leaving the definition causes the server to queue up all updates and use unnecessary directory space.Also, the supplier continues trying to contact the missing consumer to retry sending the data.