Replication conflicts occur when incompatible changes are applied concurrently to multiple read-write replicas. There are two types of conflict possible:
- Modify conflicts - these involve concurrent modifications to the same entry.
- Naming conflicts - these involve other operations that affect the DN of the entry.
Replication can resolve modify conflicts and most naming conflicts without intervention. However, the following types of naming conflicts cannot be resolved during replication and must be fixed manually:
- Different entries that share the same DN are added concurrently on multiple replicas.
- An entry on one replica is moved (renamed) to use the same DN as a new entry concurrently added on another replica.
- A parent entry is deleted on one replica while a child entry is added or renamed concurrently on another replica.
This is a brief summary of the information documented in Replication Conflicts.
Multiple matching entries
The following error is commonly seen when there are multiple matching entries:Plug-in org.forgerock.openam.idrepo.ldap.DJLDAPv3Repo encountered a ldap exception. ldap errorcode=95
This error can occur in a variety of scenarios, including (but are not limited to) the following common examples:
- SSO in a federated environment; see Authentication fails with Error inactivating user account in AM (All versions) for further information.
- Viewing user details on the Identities page (previously the Subjects tab) or via a REST call. For example, if users are not replicating correctly between nodes, a user can be created on one node, not replicated and then re-created on the second node with a different timestamp. Once replication catches up, this error will occur since the user now exists twice.
- Viewing group details on the Identities page (previously the Subjects tab) or via a REST call when the group has the same name as another group in a different realm. This is a known limitation: OPENAM-13169 ( group names having the same CN but different full Distinguished Name Path).
You can use the logs to identify all types of replication issues; this is covered in detail in How do I troubleshoot replication issues in DS 5.x and 6.x? along with information on monitoring replication to identify issues quickly. However, if you know you have naming conflicts, you can run a ldapsearch command on ds-sync-conflict to identify the specific entries.
You must run the ldapsearch command on each node since replication conflict entries can differ across nodes. Alternatively, you can resolve the replication conflicts on one node and re-initialize the remaining nodes.
- DS 7.1 and later: $ ./ldapsearch --hostname ds1.example.com --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePassword:file /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password --baseDN "dc=example,dc=com" "(ds-sync-conflict=*)" ds-sync-conflict > replication-conflict-entries.out
- DS 7: $ ./ldapsearch --hostname ds1.example.com --port 1636 --useSsl --usePkcs12TrustStore /path/to/ds/config/keystore --trustStorePasswordFile /path/to/ds/config/keystore.pin --bindDN uid=admin --bindPassword password --baseDN "dc=example,dc=com" "(ds-sync-conflict=*)" ds-sync-conflict > replication-conflict-entries.out
- Pre-DS 7: $ ./ldapsearch --hostname ds1.example.com --port 1389 --bindDN "cn=Directory Manager" --bindPassword password --baseDN "dc=example,dc=com" "(ds-sync-conflict=*)" ds-sync-conflict > replication-conflict-entries.out
The naming conflicts written to the file would look similar to the output below (where the addition of entryuuid=[string]+ signifies a naming conflict):entryuuid=bfbbd0fd-42f4-4d54-b0b2-69b32233cec9+cn=jdoe,ou=group,ou=employees,dc=example,dc=com entryuuid=c49df422-5f96-ea2b-85a2-d921eb0c3309+uid=user1,dc=example,dc=com entryuuid=eb8ad149-aa61-ea2b-8b0f-935663bcd8ed+uid=user74,dc=example,dc=com ...
You should resolve the naming conflicts as described in the documentation: Replication Conflicts.