Multi-threaded replication

You can use the information and example provided here to know more about multi-threaded replication.

The multi-threaded replication function replaces the current single replication thread with a minimum of three threads to service the replication agreement:

Main thread
Sender thread
Receiver thread

You can have anywhere from 1 to 32 consumer connections. Set the number of consumer connections to match the number of processors on your machine.

Using multiple threads enables the supplier to send the updates to the consumer without waiting on the response from the consumer.

Anyone with a replication backlog might consider switching to multi-threaded replication. Candidate environments can include the following conditions:

A high update rate
No downlevel servers
Common AES salt and synchronization if encryption is AES and passwords are updated often
Small fanout (for example, don't try 8 connections per agreement with 24 replicas)
Available servers and reliable network
Data consistency is not critical
All replication schedules are immediate
Multiprocessor machines

Multi-threaded replication is difficult to administer if servers or networks are not reliable.

When errors occur, the errors are logged and can be replayed by the administrator, but the error logs must be monitored closely. The following search shows the replication backlog for all agreements supplied by one server:

idsldapsearch -h supplier-host -D cn=admin -w ? -s sub 
	objectclass=ibm-replicationagreement 
	ibm-replicationpendingchangecount ibm-replicationstate

If the replication state is active, and the pending count is growing, there is a backlog that won't decrease unless the update rate decreases.