Red Hat Directory Server 9.1.2 and later
Red Hat Directory Server 10.1 and later
Red Hat Enterprise Linux 6.9 and later
Red Hat Enterprise Linux 7.3 and later
Red Hat Identity Management 4.4 and later
Replication fails because of a missing change sequence number (CSN) in the local change log database.
The fundamental issues tracked in the upstream tickets
and eliminated a temporary parameter nsds5ReplicaIgnoreMissingChange to always "treating missing CSN as fatal".
The fixes appeared in:
- added 2017-08-01 : RHEL-7 with 389-ds-base-184.108.40.206-16.el7 see https://access.redhat.com/errata/RHBA-2017:2086 was tracked in https://bugzilla.redhat.com/1391700
Note the systems should always use the last provided RHEL updates.
History of the fix:
There was a temporary Red Hat Directory Server configuration parameter called nsds5ReplicaIgnoreMissingChange , that was added to the replication configuration entry.
It was tracked in upstream ticket https://pagure.io/389-ds-base/issue/49020 - do not treat missing csn as fatal
The parameter used to suport the following values:
* never or off: (Default) No alternative CSN is used. A missing CSN causes the replication to fail.
* once or on: A missing CSN is ignored once and an alternative CSN is used. If Directory Server is unable to also locate the alternative CSN, replication fails.
* always: A missing CSN is always ignored and the entry never replicated.
Example to set the nsds5ReplicaIgnoreMissingChange parameter on a Directory Server instance, was:
# ldapmodify -D "cn=Directory Manager" -W -x -p 389 -h server.example.test dn: cn=*agreement_name*,cn=cn=replica,cn=*suffixDN*,cn=mapping tree,cn=config changetype: modify replace: nsds5ReplicaIgnoreMissingChange nsds5ReplicaIgnoreMissingChange: once CTL+D
This setting did not require re-initializing the replication agreement or restarting the server to take effect.
In a Red Hat Directory Server replication environment, the supplier selects a CSN to before sending an update to the replica. If the supplier is unable to locate the CSN in the local change log database, the update cannot be sent and the supplier retries the process later. If the consumer was updated in the meantime by a different supplier, the CSN can be different and replication succeeds. However, if the supplier continuously fails to locate the CSN in the change log, replicating the entry fails.
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.