Subject: Re: Replication
From: Scott Marlowe <smarlowe@g2switchworks.com>
To: Russ Brown <pickscrape@gmail.com>
Cc: pgsql-general@postgresql.org
In-Reply-To: <4326F406.7010402@gmail.com>
References: <KGEFLMPJFBNNLNOOOPLGOEOGCIAA.simon@2ndquadrant.com>
	<4326F406.7010402@gmail.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1126637123.12728.43.camel@state.g2switchworks.com>
Mime-Version: 1.0
Date: Tue, 13 Sep 2005 13:45:23 -0500

On Tue, 2005-09-13 at 10:45, Russ Brown wrote:
> Simon Riggs wrote:
> > Barry,
> > 
> > You can use PITR to archive transaction logs to a second server that is
> > kept in standby mode.
> > 
> > This will cope with any number of tables and cope with dynamic changes
> > to tables.
> > 
> > This is fairly straightforward and very low overhead.
> > Set archive_command to a program that transfers xlog files to second
> > server.
> > Then set restore_command on the second server to a program that loops
> > until the next file is available.
> > Switchover time is low.
> > 
> 
> Apologies for going slighly off topic, but isn't this basically how 
> MySQL does replication? I ask because one of the arguments against 
> moving to PostgreSQL in my organisation is 'no replication out of the 
> box'. But if the above is true it seems that all that is required are a 
> couple of scripts to handle log transfer and you have a form of 
> replication out of the box right there.
> 
> Or am I missing something?

I don't know, but someone in your organization seems to be.

Let me present it as a simple devil's choice, which would you rather
have, proven replication, that works, but requires you to setup a
secondary bit of software / system scripts (like rsync) but is tested
and proven to work, or, an "out of the box" solution that is untested,
unreliable, and possible unsafe for your data?

Chosing a database because it has "out of the box" replication without
paying attention to how it is implemented, how well it works, and what
are the ways it can break is a recipe for (data) disaster.

I've tested slony, and I know that for what we use it for, it's a good
fit and it works well.  I've tested MySQL's replication, and it simply
can't do what I need from a replication system.  It can't be setup on
the fly on a live system with no down time, and it has reliability
issues that make it a poor choice for a 24/7 enterprise replication
system.

That said, it's a great system for content management replication, where
downtime is fine while setting up replication.

But I wouldn't choose either because it was easier to implement.  Being
easy to implement is just sauce on the turkey.  I need the meat to be
good or the sauce doesn't matter.