Re: replication

[Terry Lambert <terry@whistle.com>]

Trapp, Michael wrote:
> has anybody tested the server replication in both directions?
> as far as i can see the replication from master to slave
> works pretty well, but if a client requests a change on the
> slave side i can't get the data updated on the master...


Mututal replication is not supported by LDAP.  It is similar
to DNS or NIS in this way.

There is some work going on in the IETF LDAPEXT working
group to address this, but software has not shipped yet.


One approach is to use a back end data store which supports
mutual replication.  This is what Novell's NDS-based LDAP
server does.  OpenLDAP does not support such a back end data
store at this time.

The most common approach to this problem is to run a
"stealth master".  This works by setting up a master and
several slaves, where the master is never seen publically,
and all clients operate by reading from one of the slaves.

When a write is attempted on a slave, the slave returns a
referral to the real master; thus the master is only ever
used by slaves for replication, and is only ever used by
clients for writing.

In other words, the only place software will know about
the master is (A) when a slave has been explicitly set up
to know about the master, or (B) when client software
follows a referral after attempting a write.


If you want to use a bak-end data store, then you will
need to write the code yourself, in order to be able to
store data in a Postgress or MySQL or other database that
supports mutual replication.  This is not a trivial task.

Note that there is a trick you will have to use for this
to work: you will need to split your key space into two
pieces: one per server piece, and one common piece.  This
will let you write to multiple servers, without resulting
in a key space conflict.

Since your replication will be by way of an out-of-band
mechanism peculiar to the data store you select to write
your new back end for, you will technically be running a
multi-master configuration, not a master/slave one.

If you do this, I recommend doing what IBM did with their
SecureWay LDAP server (which is built on DB2) and just
index everything.


-- Terry Lambert
-- Whistle Communications, Inc., an I.B.M. Company
-- terry@whistle.com
-------------------------------------------------------------------
This is formal notice under California Assembly Bill 1629, enacted
9/26/98 that any UCE sent to my email address will be billed $50
per incident to the legally allowed maximum of $25,000.