Replication conflict resolution

You can know more about replication conflicts and ways to resolve those by reading the information provided here.

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 Utilities for logging 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 Command Reference for information on resynchronizing servers.

To enhance the replication conflict resolution mechanism, the granularity of the timestamps is set to microseconds. Security 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 Security 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 Security Directory Server 6.0 and above versions, to resolve replication conflict it needs the supplier to provide the entry'stimestamp 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 Security Directory Server version 6.0 server in this case, takes the replicated timestamp and updates and applies it without conflict checking.

Note:

Earlier versions of IBM Security Directory Server do not support time stamp conflict resolution.If your topology contains earlier versions of IBM Security Directory Server, data consistency is not ensured for the network. See 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 WebSphere® Application Server Edge Components, 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.

Security 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.

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