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" <[email protected]> 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) <[email protected]> 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/[email protected]/msg00109.html) >> suggest or would that be just wrong? >> >> Regards, >> Torsten >> >>
