On Thu, Apr 09, 2026 at 03:04:50AM +0000, Hawes, David wrote:
While testing n-way multi-provider with delta-syncrepl, I stumbled upon a sequence of events that leaves a consumer out of sync.
Assume two providers, provider-1, and provider-2, and a single consumer, consumer-1. They all initially have an attribute with the value 'A'. The following events cause the consumer to be out of sync:
- Shut down provider-2, and immediately start it again.
- Within the syncrepl retry window, modify the attribute to value 'B' on provider-2.
- Within the syncrepl retry window, modify the attribute to value 'B' on provider-1, and then to value 'A' on provider-1.
- Wait for provider-1 and consumer-1 to retry syncrepl against provider-2.
At this point provider-1 and provider-2 will be in sync, but consumer-2 will have the value 'B'. On retry, the modify from provider-2 is written to consumer-1, even though it is older than the modifications it received from provider-1.
Before I go too far down the rabbit hole (I've stopped at syncrepl.c:3271 in 2.6.13), I want to ask if n-way multi-provider with delta-syncrepl and a consumer that the providers are unaware of (no syncrepl directives to the consumer) is a valid config. Ideally I'd like to have a consumer with multimaster off to prevent writes completely, and I'd note that config has the same result. Normal syncrepl does not result in an out of sync consumer.
So, is this an invalid config, or should I submit an ITS?
Hello David, it depends.
Deltasync MPR works if conflicting modifications don't reach the consumers out of CSN order. And providers themselves know how to resolve ambiguities by checking their accesslog to see if (parts of) the modification got overshadowed by newer ones (but see ITS#9341 and ITS#10178 for caveats).
You should be able to get around this particular scenario by configuring accesslog on your consumer the way you do on providers, AFAIK it will try and do the same work a provider would have. But if you expect clients to actively issue conflicting modifications/deletes against the same DNs, your best bet would be to switch to plain syncrepl.
Regards,