8.18. Solving Common Replication Conflicts

Multi-master replication uses a loose consistency replication model. This means that the same entries can be changed on different servers. When replication occurs between the two servers, the conflicting changes need to be resolved. Mostly, resolution occurs automatically, based on the timestamp associated with the change on each server. The most recent change takes precedence.

However, there are some cases where change conflicts require manual intervention in order to reach a resolution. Entries that have a change conflict that cannot be resolved automatically by the replication process contain a conflict marker attribute nsds5ReplConflict. The nsds5ReplConflict attribute is an operational attribute which is indexed for presence and equality, so it is simple to search for entries that contain this attribute. For example:

ldapsearch -D adminDN -w password 
      -b "dc=example,dc=com" "nsds5ReplConflict=*" \* nsds5ReplConflict

The nsds5ReplConflict attribute is already indexed for presence and equality, but for performance reasons, if there are many conflicting entries every day, index the nsds5ReplConflict attribute in other indexes. For information on indexing, see Chapter 10, Managing Indexes.

This section contains the procedures for the following conflict resolution procedures:

8.18.1. Solving Naming Conflicts

When two entries are created with the same DN on different servers, the automatic conflict resolution procedure during replication renames the last entry created, including the entry's unique identifier in the DN. Every directory entry includes a unique identifier given by the operational attribute nsuniqueid. When a naming conflict occurs, this unique ID is appended to the non-unique DN.

For example, the entry uid=adamss,ou=people,dc=example,dc=com is created on Server A at time t1 and on Server B at time t2, where t2 is greater (or later) than t1. After replication, Server A and Server B both hold the following entries:

uid=adamss,ou=people,dc=example,dc=com (created at time t1)
nsuniqueid=66446001-1dd211b2+uid=adamss,dc=example,dc=com (created at time t2)

The second entry needs to be renamed in such a way that it has a unique DN. The renaming procedure depends on whether the naming attribute is single-valued or multi-valued.

8.18.1.1. Renaming an Entry with a Multi-Valued Naming Attribute

To rename an entry that has a multi-valued naming attribute, do the following:

Rename the entry using a new value for the naming attribute, and keep the old RDN. For example:

ldapmodify -D adminDN -w password 
  dn: nsuniqueid=66446001-1dd211b2+uid=adamss,dc=example,dc=com 
  changetype: modrdn
  newrdn: uid=NewValue
  deleteoldrdn: 0

Remove the old RDN value of the naming attribute and the conflict marker attribute. For example:

ldapmodify -D adminDN -w password
  dn: uid=NewValue,dc=example,dc=com 
  changetype: modify 
  delete: uid 
  uid: adamss 
  - 
  delete: nsds5ReplConflict 
  -

NOTE

The unique identifier attribute nsuniqueid cannot be deleted.

For more information on the ldapmodify command, see Section 2.2, “Managing Entries from the Command-Line” and the Directory Server Configuration, Command, and File Reference.

The Console does not support editing multi-valued RDNs. For example, if there are two servers in a multi-master mode, an entry can be created on each server with the same user ID, and then the new entries' RDN changed to the nsuniqueid uid value. Attempting to modify this entry from the Console returns the error Changes cannot be saved for entries with multi-valued RDNs.

Opening the entry in the advanced mode shows that the naming attribute has been set to nsuniqueid uid. However, the entry cannot be changed or corrected by changing the user ID and RDN values to something different. For example, if jdoe was the user ID and it should be changed to jdoe1, it cannot be done from the Console. Instead, use the ldapmodify command:

dn: cn=John Doe
  changetype: modify 
  replace: uid 
  uid: jdoe 

  dn: cn=John Doe 
  changetype: modrdn 
  newrdn: uid=jdoe1 
  deleteoldrdn: 1

8.18.1.2. Renaming an Entry with a Single-Valued Naming Attribute

To rename an entry that has a single-valued naming attribute, do the following:

Rename the entry using a different naming attribute, and keep the old RDN. For example:

ldapmodify -D adminDN -w password 
  dn: nsuniqueid=66446001-1dd211b2+dc=pubs,dc=example,dc=com 
  changetype: modrdn 
  newrdn: cn=TempValue
  deleteoldrdn: 0

Remove the old RDN value of the naming attribute and the conflict marker attribute. For example:

ldapmodify -D adminDN -w password
  dn: cn=TempValue,dc=example,dc=com 
  changetype: modify 
  delete: dc 
  dc: pubs 
  - 
  delete: nsds5ReplConflict 
  -

NOTE

The unique identifier attribute nsuniqueid cannot be deleted.

Rename the entry with the intended attribute-value pair. For example:
```
ldapmodify -D adminDN -w password
  dn: cn=TempValue,dc=example,dc=com 
  changetype: modrdn 
  newrdn: dc=NewValue
  deleteoldrdn: 1
```
Setting the value of the deleteoldrdn attribute to 1 deletes the temporary attribute-value pair cn=TempValue. To keep this attribute, set the value of the deleteoldrdn attribute to 0.

For more information on the ldapmodify command, see Section 2.2, “Managing Entries from the Command-Line” and the Directory Server Configuration, Command, and File Reference.

8.18.2. Solving Orphan Entry Conflicts

When a delete operation is replicated and the consumer server finds that the entry to be deleted has child entries, the conflict resolution procedure creates a glue entry to avoid having orphaned entries in the directory.

In the same way, when an add operation is replicated and the consumer server cannot find the parent entry, the conflict resolution procedure creates a glue entry representing the parent so that the new entry is not an orphan entry.

Glue entries are temporary entries that include the object classes glue and extensibleObject. Glue entries can be created in several ways:

If the conflict resolution procedure finds a deleted entry with a matching unique identifier, the glue entry is a resurrection of that entry, with the addition of the glue object class and the nsds5ReplConflict attribute.
In such cases, either modify the glue entry to remove the glue object class and the nsds5ReplConflict attribute to keep the entry as a normal entry or delete the glue entry and its child entries.
The server creates a minimalistic entry with the glue and extensibleObject object classes.

In such cases, modify the entry to turn it into a meaningful entry or delete it and all of its child entries.

8.18.3. Solving Potential Interoperability Problems

For reasons of interoperability with applications that rely on attribute uniqueness, such as a mail server, it may be necessary to restrict access to the entries which contain the nsds5ReplConflict attribute. If access is not restricted to these entries, then the applications requiring one attribute only pick up both the original entry and the conflict resolution entry containing the nsds5ReplConflict, and operations will fail.

To restrict access, modify the default ACI that grants anonymous read access:

ldapmodify -h hostname -D "cn=Directory Manager" -w password 
> dn: dc=example,dc=com
> changetype: modify
> delete: aci
> aci: (target ="ldap:///dc=example,dc=com")(targetattr
    !="userPassword")(version 3.0;acl "Anonymous read-search
    access";allow (read, search, compare)(userdn = "ldap:///anyone");)
> -
> add: aci
> aci: (target="ldap:///dc=example,dc=com")(targetattr!="userPassword") 
    (targetfilter="(!(nsds5ReplConflict=*))")(version 3.0;acl
    "Anonymous read-search access";allow (read, search, compare)
    (userdn="ldap:///anyone");)
> -

The new ACI filters out all entries that contain the nsds5ReplConflict attribute from search results.

For more information on the ldapmodify command, see Section 2.2, “Managing Entries from the Command-Line” and the Directory Server Configuration, Command, and File Reference.