[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Backends for Reliability

Ian A. Tegebo wrote:
On Sun, Feb 05, 2006 at 10:07:08AM -0800, Howard Chu wrote:
Note that BDB's replication mechanism is also single-master, so it offers no advantage over OpenLDAP's existing mechanisms.
What about the following line from the following page:

"If the master environment fails, applications may upgrade a client to
be the new master."

Perhaps this feature is new? From the changelogs, I don't see recent
"multi-master" additions though. Maybe it was client-client sync:

It's not unique to BDB though. With the existing OpenLDAP 2.3 releases you can manually upgrade any slave to be a new master without interrupting service (using back-config).

And BDB's replication is all-inclusive; as such it does not support fractional or partial replication, and it precludes any differences in indexing between master and slaves.
True, syncrepl does have rockin' features; the thought about BDB
replication is that it would sit on top of several machines whose
biggest job would be replication of the site's databases. But your
point about indexing would imply that this would be bad for performance
(given that varying data needs in one BDB database would adversely
affect another). I don't know that it would be so bad to just have
multiple instances of BDB replication across the cluster.

I guess if your deployment calls for identical information/indexing everywhere, then BDB replication would be OK.

Right now, only masters/providers can modify their backends from client
requests. So if the master/provider goes down, the slaves/consumers may
have the data, but they cannot accept updates nor forward requests for
writes. I cannot think of a way that slaves/consumers could failover to
another master/provider to allow updates to happen; and if that did,
you've created the problem of having to sync/rebuild the provider when
it comes back up.
It's quite simple to enable the multimaster code in slapd for automatic failover. With syncrepl a server that stopped will automatically resync itself when it restarts.
Do you mean slurpd has multimaster code and that this is different from
syncrepl which would have the consumers resync on startup with either
refreshOnly or refreshAndPersist? If you mean syncrepl supports
multimaster and that downed providers will sync themselves to the updated
providers on restart, then count me in.

It's a feature of slapd, not slurpd or syncrepl. In the released code you enable it by compiling slapd with -DSLAPD_MULTIMASTER. (Or setting ol_enable_multimaster=yes before running configure; it's the same.)

I didn't see anything in the changelogs or in FAQ-O-Matic. But the lists had something to say:

You would have to go back pretty far in the changelogs to see it, since it has been there since August 1999.

A statement about multi-master not supported (not replied to):
-the FAQ: http://www.openldap.org/faq/data/cache/1240.html
One saying multi-master is harmful:

The above statements still stand. "True" multimaster, as most people advertise it and think of it, is pure BS. The project discourages it, for many good reasons that can be found in your above references. But as a mechanism for automatic failover, it may be useful.

It's important though to be very clear about what it actually offers you. If you lose connectivity with a master because of a network partition, then "automatic failover" can just compound the problem with more headaches. Typically a particular machine cannot distinguish between losing contact with a peer because the peer crashed, or because the network link has failed. If you have a network partition and multiple clients start writing to each of your "masters" then reconciliation will be a pain; it may be best to simply deny writes to the clients that are partitioned from the single master.

But I'm not sure how to proceed after running configure and setting this
variable.  I'd love to setup automatic failover, I saw someone in the
lists that used heartbeat:


Is this what you're referring to?

That's one possibility.

 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/