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?)