[Date Prev][Date Next]
Re: How to bootstrap in mirror mode with cn=config
I see your point, and actually, this is what we are doing anyway.
But I could ask my question in a different way as well:
How would I turn a single server in to a mirror mode pair?
> a server2 backup avoids problems with serverId etc.
You know, I am asking because I want to understand those problems.
P.S.: The list doesn't have the reply-tp header properly set. Make sure
manually to reply tot he list.
On Thu, 16 Sep 2010 19:52:01 +1000, "Brett @Google"
> I'd suggest a less complex approach.
> Restore server2 from backup, but make sure you emit a backup ldif
> somewhere on a backed up filesystem daily or whatever.
> After restoring your server 2 ldif, you will be configured, and will
> recover data quicker if you have some relatively static data sets.
> Building a replica with syncrepl can be slower than slapcat, restoring
> a server2 backup avoids problems with serverId etc., even with newer
> openldap versions.
> On 9/16/10, Torsten Schlabach (Tascel eG) <firstname.lastname@example.org> wrote:
>> Dear list!
>> I am currently chasing some replication problems and I am trying to get
>> mind around a couple of questions.
>> Let's assume this:
>> We have two LDAP servers, server 1 and server 2, which are supposed to
>> mirrors of each other.
>> The both have their cn=config database and a database with actual data,
>> let's assume it's the dc=example,dc=com database.
>> I want to run not only dc=example,dc=com but also cn=config in mirror
>> to make sure that I keep the config in sync and that any changes to the
>> config (e.g. ACls) can be done on one of the servers and will replicate
>> the other one.
>> Let's assume this was all working well.
>> Not server 2 fails and needs a complete reinstall. So I sit there with
>> slapd binary and no configuration at all.
>> My idea would be (please tell me if I am on the right path) :
>> 1. I could give server 2 a minimal config which does not contain
>> else but "replicate your cn=config from server1". Let's call this a
>> bootstrap config.
>> 2. Once server 2 starts with that bootstrap config, it will fetch
>> cn=config from server1.
>> 3. It will learn from the replicated config that it has to have an
>> dc=example,dc=com database, create it and replicate its content from
>> server1 as well.
>> 4. I would be back in business.
>> Unfortunately, when I tried, what happened was:
>> The contextCSN of the bootstrap config on server 2 is newer / higher
>> the one on server 1 which has not been touched for a while. So server 2
>> not fetch the config from server 1 but vice versa, which was not
>> the result I intended. Though it's very consequent and logical
>> My question:
>> Am I on the complete wrtong track?
>> Would I have to do the slapcat -> slapadd thing between server 1 and
>> server 2 first (with server 2 offline) and start server 2 only after
>> When I do the slapcat / slapadd thing from server 1 to server 2, do I
>> to remove any contextCSN / entryCSN entries (as some postings such as
>> suggest or would that be just wrong?