Search Postgresql Archives

Re: Bigtime scaling of Postgresql (cluster and stuff I suppose)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux