Re: Cluster/redundancy question - Mailing list pgsql-general

From Scott Marlowe
Subject Re: Cluster/redundancy question
Date
Msg-id 1129048701.29961.102.camel@state.g2switchworks.com
Whole thread Raw
In response to Cluster/redundancy question  (Travis Brady <travis.brady@gmail.com>)
Responses Re: Cluster/redundancy question  (Alex Stapleton <alexs@advfn.com>)
Re: Cluster/redundancy question  (Andrew Sullivan <ajs@crankycanuck.ca>)
List pgsql-general
On Mon, 2005-10-10 at 15:16, Travis Brady wrote:
> All,
>
> Forgive me if this has been answered before, but I've searched the
> archives and the net extensively and have come up mostly empty so far.
>
> I'm working at convincing my firm to implement a postgresql database
> cluster.
> Specifically, we'd like to get a few machines running to be more
> available and to protect against any kind of failure.
>
> Right now people are leaning toward MySQL and Emic, but I've been
> evangelizing for postgres for the standard reasons.
> How does one go about setting this kind of thing up?
> I've looked at Bizgres and Pervasive but I'm not sure if that's
> necessarily what we want.

If you're looking at the replication systems FIRST, then you've missed a
few steps.  Look at what the databases, sans replication, can bring to
the table, and what they lack.

If you MUST have a database that checks input against check constraints,
then MySQL is out.  It simply doesn't support them.

If you need a database that converts the number 234987234987234987234
into 2147483647 when you insert it into an int field and doesn't throw
an error or warning, then MySQL should be your choice.

How important is good transactional performance?  MySQL has serious
limitations for certain storage engines and you need to compare those
things before looking at replication.

Don't get me wrong, if replication is one of the things you need, then
consider it, but if you're putting bad data into your database, what
good is replicating it gonna do ya?

pgsql-general by date:

Previous
From: Bricklen Anderson
Date:
Subject: Re: fine tuned database dump/reload?
Next
From: Douglas McNaught
Date:
Subject: Re: fine tuned database dump/reload?