Preventive Service Planning
This document applies only to the following language version(s):
Tivoli Directory Server replication changes on different queues are independent. Synchronization of replication changes on different queues is not feasible.
In TDS replication setup there may be more than one replication queue on different replication contexts from a supplier (server that sends changes) to a consumer (server that gets the changes). The changes sent on any of these replication queues do not depend on the changes sent in any other replication queue.
Its not feasible to synchronize different replication queues. For the business case where order of replication changes on different queues is important, replication must be reconfigured to put such entries under the same replication context (or suffix).
Consider a supplier LDAP server with an user container(branch) "cn=users,dc=com" which holds all user specific information and a group container(branch) "cn=groups,dc=com" which holds all the group information,
If these two containers (branches) "cn=users,dc=com" and "cn=groups,dc=com" are configured as separate replication contexts with different replication agreements(queues) leading to consumer, then there will be two different replication queues, one under each container (branch).
1. In a master-master replication setup between two TDS LDAP servers on the two branches as mentioned above.
2. Second master goes/brought down due to some outage/maintenance.
3. An user gets added on first master under "cn=users,dc=com" and group member information is updated under "cn=groups,dc=com".
4. These changes are queued up on two different replication queues from first master to second master, one for suffix "cn=users,dc=com" and another for "cn=groups,dc=com".
5. Later the group gets updated to remove the membership and then the user gets deleted.
6. Later when second master comes up, replication from first master resumes.
7. The changes on the queues happen independent of each other and may lead to error and conflicting conditions based on which set of changes reaches the consumer first.
Since the replication queue changes are independent, its recommended to keep dependent branches under a single replication context (suffix). Instead of configuring the replication on "cn=users,dc=com" and "cn=groups,dc=com", configure the replication context to be dc=com. Now the replication changes happening with in the dc=com branch will be sent in the same order as its received by the supplier from client applications.