I have a syncrepl setup where some slaves get a portion of the full DIT that is defined by access-control on the master. This works well until the ACLs change or some other data update (such as group membership) allows the slave to see a different subset of the DIT. The problem is twofold:
1) The slave might now have data that it should delete.
2) The slave might now be allowed to see more data so it should replicate it.
The current syncrepl implementation does not seem to handle this case very well on its own, and I don't want to delete the whole of the slave DB. Is there aome way that I can force a complete re-sync on a live server? I tried deleting the contextCSN through LDAP, but of course it won't let me do that on the slave.
Andrew
--On Wednesday, June 18, 2008 7:23 PM +0100 Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
The current syncrepl implementation does not seem to handle this case very well on its own, and I don't want to delete the whole of the slave DB. Is there aome way that I can force a complete re-sync on a live server? I tried deleting the contextCSN through LDAP, but of course it won't let me do that on the slave.
Reset the cookie with the -c option to slapd when you start it on the slave server.
However, what you are doing is not supported for a reason. You aren't supposed to be changing the dataset the slave is supposed to replicate like that without forcing a reload of the DB (which is what -c is going to essentially do).
It'd be interesting to be able to slapcat a master with a given set of permissions in place so you could just create an LDIF dump specific to that replica...
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Wed, Jun 18, 2008 at 11:47:29AM -0700, Quanah Gibson-Mount wrote:
Is there some way that I can force a complete re-sync on a live server? I tried deleting the contextCSN through LDAP, but of course it won't let me do that on the slave.
Reset the cookie with the -c option to slapd when you start it on the slave server.
Yes - that almost does what I want... Using '-c rid=1,csn=0' causes the slave to collect things that it could not see before, but does not seem to make it delete things that it now cannot see in the master. Rather odd, as the master logs having sent a result for every entry in the new visible set so I imagined that was the 'present' phase of the replication.
However, what you are doing is not supported for a reason. You aren't supposed to be changing the dataset the slave is supposed to replicate like that without forcing a reload of the DB (which is what -c is going to essentially do).
True, but it would be handy :-)
I am thinking of the case where the slave server is in a more exposed position than the master (maybe outside a firewall). In such a case it would be silly to trust the slave to only take what it is 'supposed' to have, so the replication subset has to be defined by ACLs on the master.
It'd be interesting to be able to slapcat a master with a given set of permissions in place so you could just create an LDIF dump specific to that replica...
Yes. Trivial via LDAP of course, but rather slower.
Andrew
--On Friday, June 20, 2008 11:40 AM +0100 Andrew Findlay andrew.findlay@skills-1st.co.uk wrote:
However, what you are doing is not supported for a reason. You aren't supposed to be changing the dataset the slave is supposed to replicate like that without forcing a reload of the DB (which is what -c is going to essentially do).
True, but it would be handy :-)
I am thinking of the case where the slave server is in a more exposed position than the master (maybe outside a firewall). In such a case it would be silly to trust the slave to only take what it is 'supposed' to have, so the replication subset has to be defined by ACLs on the master.
I'm not saying you can't have a replica that holds a subset of data compared to the master. I'm just saying don't keep changing the subset the replica is supposed to hold, otherwise you'll have to force the replica to be reloaded from scratch.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
openldap-software@openldap.org
-
Andrew Findlay -
Quanah Gibson-Mount