Re: resynchronizing partial replica after ACL change

[Ferenc Wagner <wferi@niif.hu>]

Howard Chu <hyc@symas.com> writes:

> Ferenc Wagner wrote:
>
>> I'm running a couple of partial replicas, where the replicated content
>> is narrowed by provider ACLs.  All is fine.  Now, I need to extend the
>> replicas with a new attribute, so I extend the ACL to allow reading of
>> this attribute as well.  How can I get the replicas synchronize this new
>> attribute without downtime?  Is forcing a full reload by slapd -c rid=1
>> a good solution?
>
> That should work, for a standard provider/consumer replication.

Pretty standard, I guess.  But for the future: where's the catch?  For what
setups would this fail to work?

Also, this slapd restart mean at least some downtime.  Is there a way to
trigger such resync online, without slapd being stopped at all?  If not,
is there a fundemental problem stopping the implementation of such a
feature?

>> Does that incur the slapd restart downtime only, or would the replica
>> database be in a crippled state until the full resync finishes?
>
> No crippled state. Just inconsistent, since some entries will have the
> new attributes and others won't have updated yet.

That's fine, the new attributes are not used on the replicas yet.  Going
further: how do I know that the resync finished, thus the above
inconsistencies are already washed out?

In general: are matching contextCSNs of a given suffix on the provider
and the consumer equivalent to the replication being idle?  (In my case
the ACL change does not modify the contextCSN of the provider, so this
does not matter, but I'd like to devise a sound and efficient way of
monitoring the replication.  Also, some measure of the replication delay
would be useful for trending, does slapd collect such info?)
-- 
Thanks,
Feri.