A new configuration parameter nsds5ReplicaIgnoreMissingChange has been introduced to the replication agreement. The param takes either of the 3 values: never, once or always. If the value is ... - never | off: treat missing CSN as fatal - once | on: ignore a missing CSN once; treat the second missing CSN as fatal - always: ignore missing CSNs The default value is 'never | off'.
I haven't seen a reply to Noriko's suggestion of not documenting it in the general docs but only in the knowledge base. But here is a a short description. In a replication session the supplier determines a csn to start sending updates to the consumer. If it cannot find this csn in its changelog, it cannot proceede and goes int backoff and will retry later. In a later session the consumer might have been updated by an other supplier and the start csn can be different. But if the situation persists and replication does not continue the parameter nsds5ReplicaIgnoreMissingChange allows to use an alternative start csn which can be found. The default is not to use an alternative csn, to do a "kick start" of replication it can be set to "once" and it will use the alternative only once. If an admin wants to keep replication always going, it can be set to "always", but this is not recommended
We documented this parameter in a KCS that is now available on the Customer Portal: https://access.redhat.com/node/2853491/
Thanks to Brian who found an issue in the KB doc. https://access.redhat.com/node/2853491/ The entry to add the parameter nsds5ReplicaIgnoreMissingChange is not a replica entry, but an agreement underneath. Current> dn: cn=cn=replica,cn=*suffixDN*,cn=mapping tree,cn=config Correct> dn: cn=*agreement_name*,cn=replica,cn=*suffixDN*,cn=mapping tree,cn=config Sorry, Marc. I missed it in my review... For more details, please take a look at the #c21 and #c22 in the original bug [1]. Also, as suggested by Brian, it'd be useful to add that modifying the parameter is dynamic (== no need to restart the server after adding it) and no need to run the replica initialization on the agreement, either. Ludwig, please correct me if I'm wrong. ;) [1] https://bugzilla.redhat.com/show_bug.cgi?id=1391700
(In reply to Noriko Hosoi from comment #5) > So, at the point, the environment will include RHDS 9.1 / RHEL 6.9. I set a reminder and I will update the KCS article on 2017-03-21. (In reply to Noriko Hosoi from comment #7) I updated the KCS article. It now includes the correct DN and the information that neither re-initializing the replication agreement nor restarting the server is required (Ludwig confirmed this).
Thank you for updating the KCS, Marc! Looks great.