Re: How to bootstrap in mirror mode with cn=config

["Torsten Schlabach (Tascel eG)" <tschlabach@tascel.net>]

Hi Brett!

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?

> restoring
> a server2 backup avoids problems with serverId etc.

You know, I am asking because I want to understand those problems.

Regards,
Torsten

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"
<brett.maxfield@gmail.com> wrote:
> 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) <tschlabach@tascel.net> wrote:
>> Dear list!
>>
>> I am currently chasing some replication problems and I am trying to get
>> my
>> mind around a couple of questions.
>>
>> Let's assume this:
>>
>> We have two LDAP servers, server 1 and server 2, which are supposed to
be
>> 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
>> mode
>> 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
>> to
>> 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
a
>> 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
anything
>> 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
than
>> the one on server 1 which has not been touched for a while. So server 2
>> did
>> not fetch the config from server 1 but vice versa, which was not
exactly
>> the result I intended. Though it's very consequent and logical
behaviour.
>>
>> 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
>> that?
>>
>> When I do the slapcat / slapadd thing from server 1 to server 2, do I
>> have
>> to remove any contextCSN / entryCSN entries (as some postings such as
>>
http://www.mail-archive.com/openldap-technical@openldap.org/msg00109.html)
>> suggest or would that be just wrong?
>>
>> Regards,
>> Torsten
>>
>>