Re: Backends for Reliability

[Howard Chu <hyc@symas.com>]

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."
> 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:
>   

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):
> 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
>   

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:
>
> http://www.linux-ha.org/
>
> 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/