fP transaction-based clustering - viability?

[Bill Vermillion]

On Fri, Nov 05 05:56 , while impersonating an expert on the internet, 
Fairlight sent this to stdout: 


> I'm curious how many people have multiple fP servers out there
> which have data on them that they wish to keep synchronised in
> near-realtime (say less than 2min propogation) or in -actual-
> full realtime, in a transactional fashion.

I looked into this years ago.

> Several people are using rsync, ftp, scp, et al. as more
> periodic (nightly or a few times per day) backup/sync
> "solutions", but that simply doesn't cut it if you have two or
> five web servers, all of which are supposed to be load-balanced
> and serving the same data at any given point, or if you have
> multiple servers which are used to balance the load of internal
> operations but run into the same issue--all data isn't always
> present on every server immediately. And even rsync isn't
> safe for realtime work when files are in use. Too many timing
> issues. NFS has its definite downsides--even using v3 of NFS.

I'd never trust rsync for that - as you are editing active
database files. 

The approach I was going to implement - before the client decided
against mutiple locations was different.

First - none of the data entry operators ever put data in the live
data base. Therw was a two-step process.  Two identical databases.
One was for data entry only.  When the data was entered a
supervisor checked it and posted it to the live data base.

I was going to make what was essentially a two-part process, whe
the data would post to the main file and also to an export file
that would be transmitted to the far sites and the applied there.

The problem is that if data is modified on any of the the servers
does it have to propate back, or is there one place where data is
entered and then just spread around.

> We need transactions, IMHO. At least -some- places do. I'm
> trying to get a feel for the bigger picture, and whether this
> is worth the expenditure of time and effort to design and get
> it working reliably. It's not what I'd call a trivial or even
> semi-trivial "pet" project that I usually work on in my Copious
> Spare Time. :)

> So...I'm asking, up-front and out-loud, whether anyone else
> here at all is interested in such a synchronisation scenario
> coming to fruition (*unix or 'doze...doesn't matter with what
> I have in mind) as an external hook-in, since I kind of doubt
> fP-Tech will be doing this Anytime Real Soon. I'm also curious
> what those that may be interested in such a solution would
> consider sucn a solution worth in monetary terms.

So let me ask this.  Is there really a need for multiple servers or
would the system be best served by a very strong server that can
handle great loads with no problems - and then only have a failover
system if the main one goes away.

What are the statistics on these multiple machines as far as loads,
users, etc.  

I only ask becaause at times I've seen people assume the need much
horsepower than they really need - often because they've read
something about load-balancing, clusterss, etc.

And what they wind up with is an overly-complex system where a
simpler system may have sufficed.  One more powerful system may be
better than three less power systems.  You also have the question
of access on the load balanced ones if they are all coming in on
the same connection - unless it is a truly fast connection.

Bill
-- 
Bill Vermillion - bv @ wjv . com