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

["Brett @Google" <brett.maxfield@gmail.com>]

by default a server has serverId=0, so to avoid any possibility of
problems when switching a standard server to mirror mode (extra
paranoia?), you could slapcat the non-mirror mode server then remove
the replication attributes with grep etc., and then slapadd back
giving the slapadd option for creating new replication attributes
(slapadd -S 1 -w), and change the slapd serverID to 1.

start the server 1, and let it stabilize and make sure the server has
pushed it's replication state out to disk (bdb checkpoint).

then slapcat server 1, and use that to initialize server2, that way
the replication attributes will be the same, otherwise if you create
server2 with no replication attributes, they will nevertheless be
created, but more recently, and server 2 will decide it has "new" data
even if all the user attributes are actually identical, and will spend
some time re-copying the identical user data from server 1, during
which time any new changes to server 1 will be delayed replicating to
server 2 until the "new" data is replicated.

in the worst case if server2 has no user data but a "new" concrete top
level structure node which has a a newer entryCSN, it will wipe out
the other node's data entirely, which is strictly speaking correct but
serves as a rather nasty gotcha IMHO

Cheers
Brett

On 9/16/10, Torsten Schlabach (Tascel eG) <tschlabach@tascel.net> wrote:
> 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
>>>
>>>
>