Replication conflict resolution

IBM Tivoli Directory Server, Version 6.3

Replication conflict resolution

If replication conflicts occur involving delete or modifyDN operations, errors that require human intervention might result. For example, if an entry is renamed on one server while it is being modified on a second server, the rename (modifyDN) might arrive at a replica before the modify. Then when the modify arrives, it fails. In this case, the administrator needs to respond to the error by applying the modify to the entry with the new DN. All information necessary to redo the modify with the correct name is preserved in the replication and error logs. Replication errors are rare occurrences in a correctly configured replication topology, but it is not safe to assume that they never occur.

Note:

When a replication conflict is detected, an entry is re-added to resolve the replication conflict and the original entry prior to the re-add is written to the lostandfound.log file. This enables restoring any aspect of the original entry. The entire group entry can also be logged in the log file if the conflict is detected in a group entry.

Conflict resolution for add and modify operations in peer-to-peer replication is based on Timestamp. The entry update with the most recent modify TimeStamp on any server in a multi-master replication environment is the one that takes precedence. Replicated delete and rename request are accepted in the order received without conflict resolution. When a replication conflict is detected the replaced entry is archived for recovery purposes in the Lost and Found log. See Logging Utilities for more information.

Updates to the same entry made by multiple servers might cause inconsistencies in directory data because conflict resolution is based on the TimeStamp of the entries. The most recent modify TimeStamp takes precedence. If the data on your servers become inconsistent, see the ldapdiff command information in the IBM® Tivoli® Directory Server Version 6.3 Command Reference for information on resynchronizing servers.

To enhance the replication conflict resolution mechanism, the granularity of the timestamps is set to microseconds. Tivoli Directory Server also takes into consideration the fact that changes to the same entry at different times across peers may not converge because of clock skew. Therefore, to ensure convergence, each entry's timestamp is increased monotonically with every update to ensure that after an update, an entry's timestamp should never be lesser than the timestamp prior to the update operation. This ensures the convergence of entries in spite of clock skew. Therefore, replication conflict resolution will function correctly even if the system clocks of the machines in the replication topology are not in sync.

Note:

The granularity of timestamp is inconsequential in case of password policy operational attributes even though these attributes hold the timestamp value.
In Tivoli Directory Server 6.2 and above versions, timestamp granularity of entries added or modified on Windows platform will be in milliseconds. However, in case of non-Windows platform the timestamp granularity will be in microsecond. This means that if an entry is replicated from a non-Windows machine to a Windows machine the timestamp of the entry will have microsecond level granularity. On the other hand, if an entry is replicated from a Windows machine to a non-Windows machine the timestamp of the entry will have millisecond level granularity.

For IBM Tivoli Directory Server 6.0 and above versions, to resolve replication conflict it needs the supplier to provide the entry's timestamp before the entry was updated on the supplier. Downlevel versions of the directory server acting as a supplier do not have the capability to supply this kind of information. Therefore, replication conflict resolution is not applicable to cases where the supplier is a downlevel server. The consumer server which is a IBM Tivoli Directory Server version 6.0 server in this case, takes the replicated timestamp and updates and applies it without conflict checking.

Notes:

Earlier versions of IBM Tivoli Directory Server do not support time stamp conflict resolution. If your topology contains earlier versions of IBM Tivoli Directory Server, data consistency is not ensured for the network. See Appendix B. Object Identifiers (OIDs) and attributes in the root DSE and OIDs for supported and enabled capabilities to find out how to determine, if your servers support conflict resolution.
To resolve replication conflict, a regular database entry which has a later timestamp is not replaced by a replicated entry which has an earlier timestamp. However, conflict resolution does not apply to entry cn=schema which is always replaced by a replicated cn=schema.
Replication conflict resolution can be disabled on a consumer if it does not have more than one supplier in the replication topology. In such a replication topology, messages related to the conflicting operation that are logged in the ibmslapd.log file can be considered as simple warning messages. As a work around to stop logging of these messages, you can set the configuration file parameter ibm-slapdNoReplConflictResolution to true using the ldapmodify command.

Setting up a load balancer is one method of resolving data conflict resolution.

A load balancer, such as IBM WebSphere® Edge Server, has a virtual host name that applications use when sending updates to the directory. The load balancer is configured to send those updates to only one server. If that server is down, or unavailable because of a network failure, the load balancer sends the updates to the next available peer server until the first server is back on line and available. Refer to your load balancer product documentation for information on how to install and configure the load balancing server.

When conflict resolution is enabled and changes are made to the membership of a given group on two servers concurrently, conflict resolution will be triggered repeatedly and this may affect the server's performance if the groups are large.

Tivoli Directory Server enables you to selectively enable or disable replication conflict resolution for modifications to group entries by defining the value of the “ibm-slapdEnableConflictResolutionForGroups" attribute present under the “cn=Replication, cn=configuration" entry of the configuration file.

If the attribute “ibm-slapdEnableConflictResolutionForGroups" is set to FALSE then no conflict resolution will be performed even if a conflict is detected for operations on group entries like adding, deleting, or renaming an attribute of type member or uniquemember.

However, a single modify request can target multiple attributes. In such a case, if in a single modify request any other attribute other than member or uniquemember is used, then replication conflict resolution will still be performed even though the attribute “ibm-slapdEnableConflictResolutionForGroups" is set to FALSE.

Use one of the following methods to enable or disable replication conflict resolution for modifications to group entries:

Using Web Administration Tool:

If you have not done so already, click Server administration in the Web Administration navigation area and then click Manage server properties in the expanded list. Click the Conflict resolution tab.

To configure replication conflict resolution for group members, do the following:

Select the Enable replication conflict resolution for group members check box. By default, this check box is not selected. The "ibm-slapdEnableConflictResolutionForGroups" attribute under the dn "cn=Replication, cn=configuration" in the configuration file is associated with this control. This attribute can be used in all replication topologies to speed up replication by avoiding undesirable conflict resolution to group entries. The default value of the "ibm-slapdEnableConflictResolutionForGroups" attribute is FALSE.
When you are finished, do one of the following:
- Click OK to apply your changes and exit this panel.
- Click Apply to apply your changes and stay on this panel.
- Click Cancel to exit this panel without making any changes.

Using command line

To enable or disable replication conflict resolution for group members, issue the following command:

ldapmodify -h <ldaphost> -p <ldap port> -D <bindDN> -w <password> -f <file> 

where file contains:

dn:cn=Replication, cn=Configuration 
changetype: modify 
replace: ibm-slapdEnableConflictResolutionForGroups 
ibm-slapdEnableConflictResolutionForGroups: <value to be set as either TRUE or FALSE>

Disabling replication conflict resolution feature

For Tivoli Directory server 6.1 and above versions, the replication conflict resolution feature can be disabled in the following different ways:-

Manually editing the configuration file:
You can manually edit the configuration file and set the attribute "ibm-slapdNoReplConflictResolution" present under the entry "cn=master server, cn=configuration" to TRUE.

After setting this attribute value to TRUE, the server must be restarted or a readconfig operation must be issued for the changes to take effect.
Using ldapmodify utility:
You can set the value of the attribute “ibm-slapdNoReplConflictResolution" to TRUE using the ldapmodify utility as shown below:-
```
ldapmodify -D <admin_dn> -w <admin_pwd>
dn: cn=master server, cn=configuration
changetype: replace
replace: ibm-slapdNoReplConflictResolution
ibm-slapdNoReplConflictResolution: TRUE
```
The server must be restarted or a readconfig operation must be issued for the changes to take effect.
Using Web Administration Tool:
Expand the Replication management category in the navigation area and click Manage replication properties.
1. Select Default credentials and referral from the Supplier information list and click Edit.
2. From the Replication conflict resolution combo box, select the value FALSE.
3. Click OK to save your settings.

[ Top of Page | Previous Page | Next Page ]