the reason that after a total init the consumer does not have the
latest state of the supplier RUV and is receiving updates based on
the RUV at start of the total init is independent of the modrdn
problem. When a supplier is performing a total init it is still
accepting changes, the total init can take a while and there are
scenarios where an entry which is already sent is updated before
total init finishes. We cannot loose these changes.
Therfor the update resolution/ entry state resolution on the
consumer side has to handle this, ignore changes already applied and
apply new changes. And it handles it, if there are bugs they have to
Now, I am no longer sure if the fix for 48755 handles correctly all
modrdns received after the id list was prepared, the parentid might
change while the total init is on progress.
This brings up my origimal suggestion to handle the modrdn problems
also on the consumer side.
On 06/30/2016 02:34 AM, William Brown
Now that https://fedorahosted.org/389/ticket/48755 is merged, I would
like to discuss the way we handle CSN with relation to this master. As
I'm not an expert on this topic, I want to get the input of everyone
Following this document:
As I understand it, after a full online init, the replica that consumed
the changes does not set it's CSN to match the CSN of the master that
sent the changes.
As a result, after the online init, this causes a number of changes to
be replicated from the sending master to the consumer. These are ignored
by the URP, and we continue.
However, in a number of cases these are *not* ignored, and have caused
us some bugs in replication in the past. We also have some failing
changes that are skipped, which could in certain circumstance lead to
inconsistency in replicas. We have gone to a lot of effort to be able to
skip changes, to handle the case above.
The reason was is that if there was a modrdn performed, and the entry ID
of the entry that was moved was less than the new parent ID, this *had*
to be skipped, so that after the online init the modrdn change was
replayed and applied to the consumer.
Since 48755 which sorts based on the parent ID, this seems to no longer
be an issue. So we don't need to have the master replay it's changelog
out to the consumer, because the consumer is now a literal clone of the
So, is there a reason for us to leave the CSN of the consumer low to
allow this replay to occur? Or can we alter the behaviour of the
consumer to set it's CSN to the CSN of the sending master, so that we
don't need to replay these changes?
389-devel mailing list
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric Shander