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:
1. Shut down provider-2, and immediately start it again. 2. Within the syncrepl retry window, modify the attribute to value 'B' on provider-2. 3. Within the syncrepl retry window, modify the attribute to value 'B' on provider-1, and then to value 'A' on provider-1. 4. 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?
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,
Ondřej Kuzník wrote:
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).
Thanks for these links, this is exactly what I was circling around (syncrepl.c:3265) and explains the behavior I'm seeing. I do wonder if there is utility in having a directive like "multiconsumer" that would do these checks while preventing writes at the consumer. That's something I'd be willing to implement if it has merit.
I feel like these caveats are big enough to warrant a mention in the OpenLDAP admin guide, which is something else I may take a stab at.
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.
Thanks for this hint, I realized I had an accesslog on the consumer but wasn't actively writing to it. "multiprovider on" must also be set, as mentioned above.
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.
I don't actually expect this, but I was trying to increase my multi-provider understanding and put it through the paces. I've used plain delta-syncrepl for many years, but I really want to have a better HA setup to reduce downtime during upgrades. I'll have to think if these caveats are acceptable or if I want to go the mirror mode route.
Thanks again!
openldap-technical@openldap.org
-
dhawes＠vt.edu -
Hawes, David
-
Ondřej Kuzník