Re: Anyone used sequoia?
Re: Anyone used sequoia?
- Subject: Re: Anyone used sequoia?
- From: Mike Schrag <email@hidden>
- Date: Mon, 16 Apr 2007 22:10:58 -0400
I have used FrontBase's clustering, and pgcluster w/ postgresql,
which was a complete disaster (I was able to get it out of sync
fairly readily).
Hmm, okay, why was that?
All the postgresql clustering solutions are 3rd party and it's very
hard to gauge what the "production readiness" of any particular
version is. In particular, pgcluster's last "stable" release only
corresponds to PG 7.x. PG 8.x versions are all prerelease. I was
able to execute a script of starting and stopping the cluster members
that would get the cluster out of sync every time. Given that I
wasn't even loading it, I just can't put any trust into it. That and
it appears to be sort of dead (as do all of the open pg clustering
solutions). There are a couple of non-free PG clustering offerings,
but we didn't evaluate them.
FrontBase clustering "just works". It's really simple to setup
and has worked very well for us.
Sounds nice. Can you tell me a little more about it. The problem
we're trying to solve in essence is the problem where one database
is the master and the other the slave (which is seemingly read-
only). If the master goes down then nothing can be written.
Perhaps no database solves that issue - but can you tell me more
about the specifics for the clustering in terms of redundancy?
With only two databases, you can't really solve this problem in the
general case, because if the connection between the two breaks,
there's no way to know which database is "right". FrontBase has what
they call a "majority" (read page 82 of the FB Users Guide for exact
details). But essentially, with more than 2 databases, you can
establish a quorum which can determine the correctness of the
transactions. So even if you lose one (or more, depending on the
number of servers you have) of your dbs, as long as a majority is
maintained in the cluster, commits can continue. When the broken
connections come back up, the majority will be used to bring them
back into sync. You can deploy on two databases for failover, but
when a member drops that isn't manually designated the majority, it
will go read-only. FB has a lot of detail as to the exact rules for
all of this behavior. But one very important element is that two
phase commit is maintained across cluster transactions, so a majority
has to agree before a commit occurs. FB does not, however, manually
load balance your connections. But you can do this yourself just by
specifying a permutation of the cluster db ips in each app's
connection string (for FB, you specify a list of dbs in your
connection string and it uses each with decreasing priority -- if the
first is failed, it goes to the second, etc).
(Ps, We're currently deployed with mysql, so any change to
something like FrantBase ... I'd need to be able to convince some
people here... so feel free to mention any other benefits/
comparisons in this thread also ;-)
MySQL supports clustering built-in in 5.0. We were going to do some
load testing on this, but ended up just going with FrontBase for
right now, so we didn't end running these tests yet. I don't know
MySQL's commit semantics for clustering. The only thing I have read
about them is that for clustering, the entire database needs to be in
memory. So if you have an enormous database, this might be a
problem. For most people, memory is pretty cheap and this probably
isn't THAT big of a deal.
ms
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden