• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Anyone used sequoia?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Anyone used sequoia?
      • From: Kieran Kelleher <email@hidden>
    • Re: Anyone used sequoia?
      • From: Mike Schrag <email@hidden>
References: 
 >Anyone used sequoia? (From: Lachlan Deck <email@hidden>)
 >Re: Anyone used sequoia? (From: Mike Schrag <email@hidden>)
 >Re: Anyone used sequoia? (From: Lachlan Deck <email@hidden>)

  • Prev by Date: Re: Anyone used sequoia?
  • Next by Date: Re: Anyone used sequoia?
  • Previous by thread: Re: Anyone used sequoia?
  • Next by thread: Re: Anyone used sequoia?
  • Index(es):
    • Date
    • Thread