Don't forget that MySQL replication also has a habit of silently
failing on you and in my experience needs continuous monitoring to
make sure it actually keeps reasonably up to date (e.g. not days of
data behind on the slaves.)
That was a while ago though, maybe they fixed it?
British Telecom use Slony as well, so I guess it can't be *that* bad?
On 11 Oct 2005, at 17:38, Scott Marlowe wrote:
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?
---------------------------(end of
broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your
message can get through to the mailing list cleanly