On Tue, Oct 31, 2017 at 05:34:05PM +0000, ondra@openldap.org wrote:
If sessionlog data is available and found useful, syncprov will send a cookie at the end of delete phase, itself followed by the entries modified since time recorded in the client's original cookie.
Some of those entries might have been last modified before the new cookie's recorded time and if the connection is severed before this is communicated, they would not be re-sent under the new cookie.
There are other problems with this. I have always assumed that CSN of each write is globally unique in a well-configured system and that this is preserved across replication, since MMR needs that to function properly. This assumption is clearly invalid if UUIDs are sent in a delete SyncInfo message (consumer that needs to determine CSNs that apply can only pick a single CSN for all of the deletes).
So this is a problem in MMR situations where the cookie carries semantic information between MMR nodes.
An MMR member receiving such a message has to pick a CSN to apply here: - either the cookie (if present at all) - leads to problems described above - or some other CSN - the deletes could be lost or propagate to other masters as a fresh mod, either smells of replication problems down the line
This shouldn't affect deltaMMR environments, though, AFAIK they never use sessionlog in any way, so batched deletes don't get sent over the wire at all.