You should ask yourself this question: You don't expect your master LDAP server to fail frequently, if you do then you better examine other parts of you deployment. On the rare occasions that the LDAP server fails, the outages will usually be short in duration. Do you really need to allow write access to the Directory for these times the master is down? For most LDAP deployments I would think that it's not worth the investment in working out this reverse replication thing.
On Mon, 2002-10-14 at 06:43, Hugo Tavares wrote: > Greetings > > When we implement a failover recovery using the heartbeat protocol, it > really seems to work and for that I haven't any doubt (well I haven't tried > yet, but...), but I think there is a problem in keeping the DBs > synchronized. > > Having two servers (master and slave) running slapd and slurpd and the > heartbeat, and assuming that all the physical redundancy is maded: > when the masters goes down the heartbeat puts the slave being the master for > providing updates to the clients (everything is ok! till here), but, when > the master comes up the heartbeat puts everything like the original > configuration and what about the updates maded to the DB? > Two hand-maded solutions I found: > 1 - Copy yourself the DB one to another :( > 2 - You can also use OpenLDAP replication to restore the database, without > the service interruption. First, start the LDAP server on the former master > node as a slave. Then start the slurpd daemon on the current master. Changes > received while the former master was out-of service will be pushed from the > new master. Finally, stop the slave LDAP server on the former master node, > and start Heartbeat. :( > > Does anybody knows an app that deals with this? Or do we have to do it? :| > > Thks everyone > > Hugo Tavares > > > > -- > redhat-list mailing list > unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe > https://listman.redhat.com/mailman/listinfo/redhat-list -- Jeff Bearer, RCHE Webmaster, PittsburghLIVE.com Winner 2002 Eppy Award, Best U.S. Newspaper Website -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED]?subject=unsubscribe https://listman.redhat.com/mailman/listinfo/redhat-list
