Hi,
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? Does that incur the slapd restart downtime only, or would the replica database be in a crippled state until the full resync finishes?
Ferenc Wagner wrote:
Hi,
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.
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.
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?)
Ferenc Wagner wrote:
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?
In MMR, updates whose entryCSN match the entry's existing entryCSN will be ignored, so a resync attempt like this won't change anything.
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?
Submit an enhancement request to the ITS, find someone interested in coding it.
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?
Poll cn=monitor, watch the runqueue information, wait for the syncrepl thread to finish.
In general: are matching contextCSNs of a given suffix on the provider and the consumer equivalent to the replication being idle?
In general, yes.
(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?)
No. Patches welcome. But first, define exactly "delay" relative to what?
Howard Chu wrote:
Ferenc Wagner wrote:
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?
In MMR, updates whose entryCSN match the entry's existing entryCSN will be ignored, so a resync attempt like this won't change anything.
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?
Submit an enhancement request to the ITS, find someone interested in coding it.
I vaguely remember that Kurt once had the idea of "touching" an entry by sending a modify request with empty modlist.
If this "touch" would update 'entryCSN' it would be a better approach than full re-sync in case of fairly small count of affected entries. Or maybe better use an extended control for this to avoid interop issues with broken clients accidently sending such a empty modify list.
Since such a functionality would be also interesting for other LDAP server implementations discussion on ldapext mailing list / WG ;-) would be appropriate.
Ciao, Michael.
Hi,
I was wondering what spam filter was working on this message and found this in the header:
X-Spam-Report: Spam detection software, running on the system "gauss.openldap.net", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details.
So this is the openldap spam filter.
Content preview: Hi, I'm running a couple of partial replicas, where the replicated [...]
Content analysis details: (7.3 points, 5.0 required)
pts rule name description ---- ---------------------- -------------------------------------------------- 2.7 DNS_FROM_AHBL_RHSBL RBL: Envelope sender listed in dnsbl.ahbl.org 1.0 SINGLE_HEADER_2K A single header contains 2K-3K characters 3.6 FS_REPLICA Subject says "replica"
So "replica"tion messages are spam here, interesting! ;)
Marc
On Tue, Jan 13, 2015 at 10:41:27AM +0100, Marc Patermann wrote:
pts rule name description
2.7 DNS_FROM_AHBL_RHSBL RBL: Envelope sender listed in dnsbl.ahbl.org
AHBL was shut down and now returns positive results for all hosts [1]. Please remove it from the filter.
[1] http://ahbl.org/content/last-notice-wildcarding-services-jan-1st
openldap-technical@openldap.org
-
Ferenc Wagner -
Howard Chu -
Marc Patermann -
Michael Ströder -
Ryan Tandy