What are you trying to accomplish?
Add high availability to my master servers, avoiding replication.
Why avoid replication? Multimastering is not necessarily bad, if done
right. If you have two masters, but always write to one, with the
other as a hot standby, you have the high availability of multimastering
without much risk of conflicts (conflicts will only occur if someone
skips the VIP and writes conflicting data to each individual server).
They key is to avoiding this is to make only one available to clients at
any given time.
If you want high availability for ldap writes, create two master
servers
(each with their own storage/db files) in multimaster mode (2.4) or
mirror mode, and set up the load balancer such that all connections
to
the VIP go to one master, failing over to the second master if the
first
one is down.
What happens when that one master comes back again ?, will the previous
master replicate the data to it, what about conflicts ?
That's the idea. The failed master (even if you had to rebuild it from
scratch) should just sync up with the primary master - if you have to
rebuild from scratch (i.e. an empty db), leave the secondary master in
place until the primary is fully synced up before making it primary
again.
I need the master/replica to be transparent to the clients, so I should
use chaining ?
Master 1 Master2 Replica1 Replica2 (Chain)
|_________| |________|
| VIP1 |
|____________________|
| VIP2
If you really need that, that will probably work (conceptually it's
fine, but I've never actually used the OL chaining overlay, so there may
be gotchas in what it can do). Doing this will spread the connections
across many read-only servers, and only writes will "get through" to the
master. Just be sure the read-only replicas point to the Master VIP for
their chaining. What I've found, though, is that most clients really
only need read access, and the ones that need write access and can't
follow referrals tend to be small enough in usage that they can be
pointed to the master. I always consider it to be a badly designed
client if it can't split off it's read only usage from it's
administrative/write usage or follow referrals to do writes, such that
it only works using a writable master (i.e. a mail server should only
read LDAP for sending/receiving/reading mail, but administrative
purposes - anything from creating/deleting accounts to changing your
password or email preferences - should be separated/segregated out so it
can point to the master. In particular, doing something like logging
into webmail to read mail should not cause writes to the ldap server -
something the Sun webmail product, for example, is guilty of).