Solving Common Replication Conflicts

Multimaster replication uses a loose consistency replication model. This means that the same entries may be modified simultaneously on different servers. When updates are sent between the two servers, any conflicting changes must be resolved. Most resolution occurs automatically. For example, the timestamp associated with the change on each server is resolved by the most recent change taking precedence. However, some change conflicts require manual intervention to reach a resolution.

This section covers the following topics:

• Solving Replication Conflicts by Using DSCC

• Solving Replication Conflicts by Using the Command Line

• Solving Naming Conflicts

• Solving Orphan Entry Conflicts

• Solving Potential Interoperability Problems

Solving Replication Conflicts by Using DSCC

The easiest way to resolve a replication conflict is by using DSCC. See the DSCC online help for information.

Solving Replication Conflicts by Using the Command Line

You can solve replication conflicts by using the command line. Entries that have a change conflict that cannot be resolved automatically by the replication process contain the operational attribute nsds5ReplConflict as a conflict marker.

To find entries with conflicts, periodically search for entries that contain this attribute. For example, you could use the following ldapsearch command to find entries with conflicts:

$ ldapsearch -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config \
 -w - -b "dc=example,dc=com" "(nsds5ReplConflict=*)"

Note that the nsds5ReplConflict attribute is indexed by default.

Solving Naming Conflicts

Entries with identical DNs may be created on separate masters if they are created before the servers replicate the changes to each other. Upon replication, the conflict resolution mechanism will automatically rename the second entry created.

An entry with a DN naming conflict is renamed by including its unique identifier, provided by the operational attribute nsuniqueid, in its DN.

For example, if the entry uid=bjensen,ou=People,dc=example,dc=com is created simultaneously on two masters, both will have the following two entries after replication:

• uid=bjensen,ou=People,dc=example,dc=com

• nsuniqueid=66446001-1dd211b2-66225011-2ee211db+uid=bjensen,dc=example,dc=com

The second entry must be given a useful DN. You can delete the conflicting entry and add it again with a non-conflicting name. However, renaming the entry ensures that its contents have not changed. The renaming procedure depends on whether the naming attribute is single-valued or multivalued. See the following procedures.

To Rename a Conflicting Entry That has a Multivalued Naming Attribute

You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.

1. Rename the entry while keeping the old RDN value, for example:

   $ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: nsuniqueid=66446001-1dd211b2-66225011-2ee211db+uid=bjensen,dc=example,dc=com changetype: modrdn newrdn: uid=bj66446001 deleteoldrdn: 0 ^D

   You cannot delete the old RDN value in this step because it also contains the nsuniqueid operational attribute, which cannot be deleted.

2. Remove the old RDN value of the naming attribute and the conflict marker attribute, for example:

   $ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: uid=bj66446001,dc=example,dc=com changetype: modify delete: uid uid: bjensen - delete: nsds5ReplConflict ^D

To Rename a Conflicting Entry With a Single-Valued Naming Attribute

When the naming attribute in a duplicate entry is single-valued, for example dc (domain component), you cannot simply rename the entry to another value of the same attribute. Instead, you must give the entry a temporary name.

You can use DSCC to perform this task. For information, see Directory Service Control Center Interface and the DSCC online help.

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

   $ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: nsuniqueid=66446001-1dd211b2-66225011-2ee211db+dc=HR,dc=example,dc=com changetype: modrdn newrdn: o=TempHREntry deleteoldrdn: 0 ^D

   You cannot delete the old RDN value in this step because it also contains the nsuniqueid operational attribute, which cannot be deleted.

2. Change the desired naming attribute to a unique value and remove the conflict marker attribute, for example:

   $ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: o=TempHREntry,dc=example,dc=com changetype: modify replace: dc dc: NewHR delete: nsds5ReplConflict ^D

3. Rename the entry back to the intended naming attribute, for example:

   $ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w - Enter bind password: dn: dc=NewHR,dc=example,dc=com changetype: modrdn newrdn: dc=HR deleteoldrdn: 1 ^D

   By setting the value of the deleteoldrdn attribute to 1, you delete the temporary attribute-value pair o=TempHREntry. If you want to keep this attribute, set the value of the deleteoldrdn attribute to 0.

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 various ways:

• If the conflict resolution procedure finds a deleted entry with a matching unique identifier, the glue entry is a resurrection of that entry. It also includes the glue object class and the nsds5ReplConflict attribute.

  In such cases, you can 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 minimal entry with the glue and extensibleObject object classes.

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

Solving Potential Interoperability Problems

For interoperability with applications that rely on attribute uniqueness, such as a mail server, you might need to restrict access to the entries that contain the nsds5ReplConflict attribute. If you do not restrict access to these entries, the applications that require only one attribute will pick up both the original entry and the conflict resolution entry that contains the nsds5ReplConflict and operations will fail.

To restrict access, you need to modify the default ACI that grants anonymous read access using the following command:

$ ldapmodify -h host2 -p 1389 -D cn=admin,cn=Administrators,cn=config -w -
Enter bind 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");)
^D

The new ACI will keep entries that contain the nsds5ReplConflict attribute from being returned in search results.