Lists: | sfpug |
---|
From: | Quinn Weaver <quinn(at)fairpath(dot)com> |
---|---|
To: | sfpug(at)postgresql(dot)org |
Subject: | Sequoia? |
Date: | 2007-02-05 21:36:57 |
Message-ID: | 20070205213657.GC51173@fu.funkspiel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | sfpug |
Hi,
Has anyone here had experience with Sequoia? I mean the database
tool, not the venture capitalist. :)
It's a sort of suped-up connection pooler/manager that sits between
your code and the database. It's supposed to manage failover
transparently, treating your databases as a "RAIDb" ("Redundant
Array of Independent Databases").
So basically it claims to slice bread, perform cold fusion, and solve
the database replication/failover problem, with zero data loss _and_
without making you change your app code. I'm wondering if anyone has
tried it and can say whether it lives up to the promise.
Any takers? I'd be very grateful for any real-world tidbits, even
(especially!) stuff like "We tried to set this up but it was too much
of a pain."
Thanks,
--
Quinn Weaver, independent contractor | President, San Francisco Perl Mongers
http://fairpath.com/ | http://sf.pm.org/
From: | Josh Berkus <josh(at)agliodbs(dot)com> |
---|---|
To: | sfpug(at)postgresql(dot)org |
Cc: | Quinn Weaver <quinn(at)fairpath(dot)com> |
Subject: | Re: Sequoia? |
Date: | 2007-02-05 21:44:32 |
Message-ID: | 200702051344.32695.josh@agliodbs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | 503 토토 사이트 추천 페치 실패 |
Quinn,
> So basically it claims to slice bread, perform cold fusion, and solve
> the database replication/failover problem, with zero data loss _and_
> without making you change your app code. I'm wondering if anyone has
> tried it and can say whether it lives up to the promise.
a) It's JDBC-only.
b) Most of the management/adminstration stuff is proprietary, and comes
with the for-pay UNI/Cluster, not the for-free Sequoia
c) It's statement-based replication, which means that it's only scalable
for workloads which are 90% or more reads. For DBs with significant
numbers of writes, Sequoia will be slower than a single server.
d) The HA/Failover capabilities are pretty good.
--
--Josh
Josh Berkus
PostgreSQL @ Sun
San Francisco
From: | Jeff Frost <jeff(at)frostconsultingllc(dot)com> |
---|---|
To: | Quinn Weaver <quinn(at)fairpath(dot)com> |
Cc: | sfpug(at)postgresql(dot)org |
Subject: | Re: Sequoia? |
Date: | 2007-02-05 21:53:33 |
Message-ID: | Pine.LNX.4.64.0702051343020.4654@discord.home.frostconsultingllc.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | sfpug |
On Mon, 5 Feb 2007, Quinn Weaver wrote:
> Hi,
>
> Has anyone here had experience with Sequoia? I mean the database
> tool, not the venture capitalist. :)
>
> http://tinyurl.com/2zcsf5
>
> It's a sort of suped-up connection pooler/manager that sits between
> your code and the database. It's supposed to manage failover
> transparently, treating your databases as a "RAIDb" ("Redundant
> Array of Independent Databases").
>
> So basically it claims to slice bread, perform cold fusion, and solve
> the database replication/failover problem, with zero data loss _and_
> without making you change your app code. I'm wondering if anyone has
> tried it and can say whether it lives up to the promise.
>
> Any takers? I'd be very grateful for any real-world tidbits, even
> (especially!) stuff like "We tried to set this up but it was too much
> of a pain."
Quinn,
A client of mine was testing Continuent's uni/cluster which is the commercial
version of Sequoia. They ended up not going with it because of problems
related to sequence synchronization and occassional lockups of the cluster
during inserts.
Looks like Josh already responded, so you'll know that it's only helpful for
mostly read workloads. It did seem quite cool and they've likely gotten the
problems we experienced fixed by now.
Also of note, that since it's statement based replication, you have to be
careful with non-deterministic queries. Contineunt does some magic with
now() and random() in normal queries, but if you call these in functions you
are going to have problems. Also, I recall there are some special cases to
consider if you use triggers.
If your workload is a good fit, then you should consider evaluating it.
--
Jeff Frost, Owner <jeff(at)frostconsultingllc(dot)com>
Frost Consulting, LLC http://www.frostconsultingllc.com/
Phone: 650-780-7908 FAX: 650-649-1954
From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | SF Postgres <sfpug(at)postgresql(dot)org> |
Subject: | Re: Sequoia? |
Date: | 2007-02-05 22:07:17 |
Message-ID: | 20070205220716.GB7988@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | sfpug |
On Mon, Feb 05, 2007 at 01:36:57PM -0800, Quinn Weaver wrote:
> Hi,
>
> Has anyone here had experience with Sequoia? I mean the database
> tool, not the venture capitalist. :)
>
> http://tinyurl.com/2zcsf5
In addition to what others have mentioned, it has some pretty serious
limitations:
* You can't call data-changing functions from a SELECT statement.
* You must choose in advance what tables you'll want to JOIN to one
another, as they have to be on the same box.
Cheers,
D
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
phone: +1 415 235 3778 AIM: dfetter666
Skype: davidfetter
Remember to vote!