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!