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
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) :
- 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
openldap-technical@openldap.org
-
Brett ＠Google -
Torsten Schlabach (Tascel eG)