[Date Prev][Date Next]
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).
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.
Do you mean slurpd has multimaster code and that this is different from
Right now, only masters/providers can modify their backends from clientIt'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.
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.
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/