Thank you, Ludwig. I'll run the scenario and investigate it.
On 07/06/2016 08:38 AM, Ludwig Krispenz wrote:
I have test scenario for not correctly handled modrdns during total init:
- have a database with n entries, n large enough tthat total init
takes long enough to be able to apply an update while it is running
- add two entries
-- n+1: cn=child,$SUFFIX
-- n+2: cn=parent,$SUFFIX
both have the same parentid and n+2 will be replayed after n+1
- start total update
- do a modrdn
now cn=child,cn=paren,$SUFFIX will be sent before its parent
I do not know how we can fix this, I think it is a corner case, but we
should keep it in mind
On 06/30/2016 11:53 PM, Noriko Hosoi wrote:
> On 06/30/2016 12:45 AM, Ludwig Krispenz wrote:
>> Hi William,
>> 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.
> OK... Then, RUV needs to be created at the time when the supplier
> starts online init?
> The test case would be something like this?
> 1. run online init on the supplier.
> 2. do some operation like move entries against the supplier while the
> online init is still running on the consumer.
> 3. do some operation which depends upon the previous operation done
> in the step 2.
> 4. check the consumer is healthy or not.
> Isn't it a timestamp issue from which operation should be replayed
> after the total update? Regardless of the way how to fix 48755,
> unless the step 2 operation(s) are replayed after the online init is
> done, the consumer could get broken/inconsistent?
>> 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
>> be fixed.
>> 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 wrote:
>>> Now thathttps://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
>>> about this.
>>> 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
>>> 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,
>> 389-devel mailing list
> 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
389-devel mailing list