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) :
- 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