Re: [Hampshire] High availability database

Top Page

Reply to this message
Author: Samuel Penn
Date:  
To: Hampshire LUG Discussion List
Subject: Re: [Hampshire] High availability database
On Wednesday 16 September 2009 16:58:54 Chris Simmonds wrote:
> Hugo Mills wrote:
> > On Wed, Sep 16, 2009 at 02:13:45PM +0100, Chris Simmonds wrote:
> >> Hi and thanks to everyone who replied. I'm busy researching some
> >> possibilities at the moment. However, just to clarify, the issue is high
> >> availability among the 50 or so nodes so that any node can go down and
> >> come back up again without impacting any of the others. There are no
> >> servers as such, each node is potentially both a server and a client so
> >> that if using a traditional database there needs to be some mechanism to
> >> elect a master server if the current master goes down. The trickiest
> >> case is if the network gets disrupted such that you get two separate
> >> segments for a while - each with their own master - which then get
> >> joined together again.


I've done something (vaguely) similar, which had multiple server
nodes which each served their own set of clients. Each client had
read/write capability, but only talked to its primary server. The
servers then managed synching the other servers, which in turn
pushed out the updates to their own client pool.

If a server went down, one of the other servers would take over
its clients until it came back up again (and had brought itself
uptodate on any changes since it went down). They also coped with
the network being broken, and would resync on restoration.
Servers broadcast regular heartbeats so clients and other servers
would know what was up, or wasn't, with subnets used to control
where servers broadcast information to.

In this case though, each server was on a different continent
and served clients which were geographically close. We still
only had three master servers however, and all the HA effort
was concentrated on those.

> The application is theoretical at the moment, but the requirement comes
> from a factory floor information system with multiple data entry points.


Why can't you have a reliable server (or two or three) which the many
clients then connect to? Each client is greatly simplified since
it only needs to worry about talking to one server at a time.


-- 
Be seeing you,                         http://www.glendale.org.uk
Sam.                        Mail/IM (Jabber): sam@???