Replication

Replication is a technique used by directory servers to improve performance, availability, and reliability. The replication process keeps the data in multiple directory servers synchronized. You can know more about replication benefits through the information provided here.

Replication provides three main benefits:

Redundancy of information - Replicas back up the content of their supplier servers.
Faster searches - Search requests can be spread among several different servers, instead of a single server. This improves the response time for the request completion.
Security and content filtering - Replicas can contain subsets of the data in a supplier server.

The following sections are examples of setting up replication using either the Web Administration Tool or the command line utilities, and an LDIF file. The scenarios are of increasing complexity:

One master and one replica
One master, one forwarder, and one replica
Two peer/masters, two forwarders, and four replicas.
Gateway replication.

Let us consider an example where you want to switch from a single threaded replication agreement to a multiple threaded replication agreement. Consider an example of a replication agreement on a server with server ID as wingspread-2389 to a consumer with the LDAP URL ldap://wingspread:1389:

dn: cn=wingspread-1389,ibm-replicaServerId=wingspread-2389,
ibm-replicaGroup=default,O=SAMPLE
cn: wingspread-1389
ibm-replicaconsumerid: wingspread-1389
ibm-replicacredentialsdn: cn=simple, cn=replication, cn=localhost
ibm-replicaurl: ldap://wingspread:1389
objectclass: ibm-replicationAgreement
objectclass: top

By default, the ibm-replicamethod is 1 (single threaded replication). To change the replication method and specify the number of connections to be used, issue the following ldapmodify command:

ldapmodify -D <binddn> -w <password> -p <ldapport> -v -i <file>

where file contains:

dn: cn=wingspread-1389,ibm-replicaServerId=wingspread-2389,
ibm-replicaGroup=default,O=SAMPLE
ibm-replicamethod: 2
ibm-replicaconsumerconnections: 5

To verify the data in the replication agreement, issue the following command:

ldapsearch -L -p <ldapport> 
-b cn=wingspread-1389,ibm-replicaServerId=wingspread-2389,ibm-replicaGroup=default,
O=SAMPLE objectclass=*

The following output is generated:

dn: cn=wingspread-1389,ibm-replicaServerId=wingspread-2389,
 ibm-replicaGroup=default,O=SAMPLE
cn: wingspread-1389
ibm-replicaconsumerid: wingspread-1389
ibm-replicacredentialsdn: cn=simple, cn=replication, cn=localhost
ibm-replicaurl: ldap://wingspread:1389
objectclass: ibm-replicationAgreement
objectclass: top
ibm-replicaconsumerconnections: 5
ibm-replicamethod: 2
ibm-replicationonhold: FALSE

Here, the replication method (ibm-replicamethod) value of 2 specifies that multiple threaded replication is to be used. The attribute "ibm-replicaconsumerconnections" indicates the number of connections that replication will use for sending the updates to the consumer. This value can range from 1 to 32. In this example, the supplier will establish 5 connections to the consumer to use for replication.

Note: After the replication agreement has been updated, you must restart the server for the changes to take effect.

Now, consider an example where you want to monitor replication status. Issue the following command:

ldapsearch -D <binddn> -w <password> -p <ldapport> 
-b cn=wingspread-1389,ibm-replicaServerId=wingspread-2389,ibm-replicaGroup=default,
O=SAMPLE objectclass=* +ibmrepl

The following output is generated:

cn=wingspread-1389,ibm-replicaServerId=wingspread-2389,ibm-replicaGroup=default,O=SAMPLE
ibm-replicationChangeLDIF=N/A
ibm-replicationLastActivationTime=20080707152436Z
ibm-replicationLastChangeId=4855
ibm-replicationLastFinishTime=20080707152436Z
ibm-replicationLastResult=N/A
ibm-replicationLastResultAdditional=N/A
ibm-replicationNextTime=N/A
ibm-replicationPendingChangeCount=0
ibm-replicationState=ready
ibm-replicationFailedChangeCount=0
ibm-replicationperformance=[c=0,l=10,op=0,q=0,d=0,ws=0,s=0,ds=0,wd=0,wr=0,r=0,e=0,ss=1,rs=1]
ibm-replicationperformance=[c=1,l=10,op=0,q=0,d=0,ws=0,s=0,ds=0,wd=0,wr=0,r=0,e=0,ss=1,rs=1]
ibm-replicationperformance=[c=2,l=10,op=0,q=0,d=0,ws=0,s=0,ds=0,wd=0,wr=0,r=0,e=0,ss=1,rs=1]
ibm-replicationperformance=[c=3,l=10,op=0,q=0,d=0,ws=0,s=0,ds=0,wd=0,wr=0,r=0,e=0,ss=1,rs=1]
ibm-replicationperformance=[c=4,l=10,op=0,q=0,d=0,ws=0,s=0,ds=0,wd=0,wr=0,r=0,e=0,ss=1,rs=1]

In this example there are 5 connections to the consumer. The attribute names appear to the left of the equal signs. Some replication status information attributes are only used with single threaded replication, (shown here with the value 'N/A') while others are only for multiple threaded replication. Using "+ibmrepl" you can easily request all replication status information attributes. Use "++ibmrepl" to show all the attributes including the pending changes and logged replication errors.

The "ibm-replicationperformance" attribute is applicable to replication agreements only using multiple threaded replication. For single threaded replication, this attribute will have the value 'N/A'. You can interpret the ibm-replicationperformance data in the following manner:

c=0: This is the connection number. In this example there are 5 connections. The first connection will show the most traffic. The workload will determine how often the other connections are used.
l=10: This is the size limit for each queue. There are two queues for each connection and both have the same length. There is a queue for updates to be sent on the connection (called the send queue) and a queue for updates that have been sent but no response has been received from the consumer (called the receive queue).As updates are sent, they are moved from the send queue to the receive queue. When the receive queue hits its size limit, no more updates will be sent until some responses from the consumer are received. When the send queue hits its size limit, no more updates can be assigned to the connection. When the size limit for all of the connections send queues is reached, the supplier has to wait for the consumer to process the backlog.
op=0: The replication ID of the last operation assigned to the send queue of the connection. Replication IDs are assigned to any update that is to be replicated to a consumer.
q=0: The current size of the send queue.
d=0: The count of dependent updates (an add of an entry followed by a modify of the same entry counts as a dependency and dependent updates must be assigned to the same connection so they can be applied in the correct order).
ws=0: The number of times the send queue hit the size limit.
ds=0: The number of dependent updates sent.
wd=0: The number of times the send queue waited for a dependent update before sending additional updates.
wr=0: The number of times the receive queue hit the size limit.
r=0: The number of replicated updates waiting for a response from the consumer.
e=0: The number of replication errors reported by the consumer.
ss=1: The session count for the sender thread (incremented when the connection to the consumer is established).
rs=1: The session count for the receiver thread.