Clowser, Jeff (Contractor) wrote:
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.
So in this case you would use multimaster instead of doing master/slave and upgrade the slave to a master in case of master failure ?, how different is this from mirror mode. I think a load balancer can be configured in NAT mode and this way no one can skip the VIP.
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).
Can anyone from the developers tell me if this would work ?
Now, I use VIP2 on the clients and VIP1 in the chain configuration ?
Sounds right (conceptually).
- Jeff