Re: Bigtime scaling of Postgresql (cluster and stuff I suppose) - Mailing list pgsql-general

From Trent Shipley
Subject Re: Bigtime scaling of Postgresql (cluster and stuff I suppose)
Date
Msg-id 200708271559.53875.trent_shipley@qwest.net
Whole thread Raw
In response to Re: Bigtime scaling of Postgresql (cluster and stuff I suppose)  (Andrew Sullivan <ajs@crankycanuck.ca>)
List pgsql-general
On Monday 2007-08-27 08:04, Andrew Sullivan wrote:
> On Sat, Aug 25, 2007 at 11:13:45AM -0400, Tom Lane wrote:
> > In case you hadn't noticed the disconnect between these statements:
> > if they have to be that close together, there *will* be a single point
> > of failure.  Fire in your data center, for instance, will take out every
> > copy of your data.  So as a "high availability" solution I don't find
> > it all that compelling.
>
> Indeed.  There's another issue, too, which you have to spend some
> time reading the manual to get.  The clustering stuff is _yet
> another_ table type, with subtly different semantics from other table
> types.  As usual, this means that you can blow off your foot by
> mixing table types in a transaction.  As near as I can tell, the
> cluster table type (I disremeber the name of it) cannot be run in
> strict mode, either.
>
> To answer the OP's question, you can do some "cluster-like" things by
> doing hardware clustering -- two machines attached to a RAID with
> some sort of hardware fail-over in place.
>
> I think that the MySQL cluster stuff wasn't intended as an HA
> feature, though (although they might well be selling it that way).
> It was a way to scale many small systems for certain kinds of
> workloads.  My impression is that in most cases, it's a SQL-ish
> solution to a problem where someone decided to use the SQL nail
> because that's the hammer they had.  I can think of ways you could
> use it, and I'm not surprised that Some Giant Corp is doing so.  But
> I'd be astonished if someone used it for truly valuable data.  I
> would think very hard about the qualifications of someone who
> proposed using it for financial data.
>
If it was developed by Ericson for Telco purposes then it would be designed to
be wicked fast for OLTP (billing-switching is an OLTP application) with VERY
high up time and reliable (customers and on occasion regulators get angry
when the phones dont work).  It wouldn't matter if it can be geographically
distributed.  If the switching center catches fire you're hosed anyway.

pgsql-general by date:

Previous
From: Sanjay
Date:
Subject: Creating indices on foreign keys
Next
From: Sanjay
Date:
Subject: Re: EXPLAIN ANALYZE not considering primary and unique indices!