If there is a count for the
EntryAlready Exists statistic using the
status tool, verify the problem in the sync log. For example,
the status tool displays the following information:
--- Ops Completed for 'DS1 to DS2' Sync Pipe --- Op Result : Count -----------------------:------ Success : 0 Out Of Scope : 0 Op Type Not Synced : 0 No Change Needed : 0 Entry Already Exists : 1 No Match Found : 1 Multiple Matches Found : 0 Failed During Mapping : 0 Failed At Resource : 0 Unexpected Exception : 0 Total : 2
Verify the change by viewing the <server-root>/logs/sync file to see the specific operation, which could be due to someone manually adding the entry on the target server:
op=2 changeNumber=529277 replicationCSN=00000128AD0D9BA01E960008137D replicaID=7830 pipe="DS1 to DS2" class="DEFAULT" msg="Detected ADD of uid=user.1001,ou=People, dc=example,dc=com at ldap://server1.example.com:1389, but cannot create this entry at the destination because an equivalent entry already exists at ldap://server3. example.com:3389. Details: Search using [search-criteria dn: uid=user.1001,ou=People, dc=example,dc=com attrsToGet: [*, dn]] returned results; [uid=user.1001,ou=People, dc=example,dc=com]. "
Perform the following steps to troubleshoot this type of problem:
Assuming that a possible distinguished name (DN) mapping is ill-formed,
first run the ldap-diff utility to compare the entries on the
source and destination servers. Then look at the ldap-diff results
with the mapping rules to determine shy the original search did not find a
$ bin/ldap-diff \ --outputLDIF config-difference.ldif \ --baseDN "dc=example,dc=com" \ --sourceHost server1.example.com \ --targetHost server2.example.com \ --sourcePort 1389 \ --targetPort 3389 \ --sourceBindDN "cn=Directory Manager" \ --sourceBindPassword password \ --searchFilter "(uid=1234)"
- Review the destination server access logs to verify the search and filters used to find the entry. Typically, the key correlation attributes are not synchronized.
If the mapping rule attributes are not synchronized, review the Sync Classes
and mapping rules, and use the information from the ldap-diff
results to determine why a specific attribute may not be getting updated. Some
questions to answer are as follows:
- Is there more than one Sync Class that the operation could match?
- If using an
include-filterin the mapping rules, does this exclude this operation by mistake?
- If using an attribute map, are the mappings correct? Usually, the cause
of this error is in the destination mapping attribute settings. For
example, if a set of correlation attributes is defined as:
accountNumber, and the
accountNumberchanges for some reason, future operations on this entry will fail. To resolve this, either remove
accountNumberfrom the rule, or add a second rule as:
dn,mobile. The second rule is used only if the search using the first set of attributes fails. In this case, the entry is found and the
accountNumberinformation is updated.
- If deletes are being synchronized, check to see if there was a previous delete of this entry that was not synchronized properly. In some cases, simpler logic should be used for deletes due to the available attributes in the change logs. This scenario could cause an entry to not be deleted for some reason, which would cause an issue when a new entry with the same DN is added later. Use this information for mapping rules to see why the original search did not find a match.
- Look at the destination directory server access logs to verify the search and filters it used to find the entry. Typically, the key attribute mappings are not synchronized.