Re: Replication

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.