[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Backends for Reliability
On Sun, Feb 05, 2006 at 10:07:08AM -0800, Howard Chu wrote:
> Ian A. Tegebo wrote:
> >And this is the an argument I've been putting off; I contend that slapd
> >replication is a good thing, but that there is a compelling reason to
> >include Berkeley DB replication. If I rely solely on slapd for
> >replication I can run into trouble.
> >
> >(Please correct my understanding of replication mechanisms.)
> >
>
> 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."
http://www.sleepycat.com/docs/ref/rep/intro.html
Perhaps this feature is new? From the changelogs, I don't see recent
"multi-master" additions though. Maybe it was client-client sync:
Changes since Berkeley DB 4.3.29:
New Features:
...
8. Add replication support for client-to-client synchronization. [#12110]
...
> 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.
> >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.
I didn't see anything in the changelogs or in FAQ-O-Matic. But the lists
had something to say:
A statement about multi-master not supported (not replied to):
http://www.openldap.org/lists/openldap-software/200511/msg00344.html
-the FAQ: http://www.openldap.org/faq/data/cache/1240.html
One saying multi-master is harmful:
http://www.openldap.org/lists/openldap-software/200511/msg00313.html
and I didnt' see anything in man pages or the Admin Guide. The
configure script has:
'ol_enable_multimaster=${ol_enable_multimaster-no}'
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:
http://www.linux-ha.org/
Is this what you're referring to?
--
Ian Tegebo