From: Scott Marlowe <smarlowe@g2switchworks.com>
To: Russ Brown <pickscrape@gmail.com>
Cc: pgsql-general@postgresql.org
Subject: Re: Replication
Date: Tue, 13 Sep 2005 13:45:23 -0500
Message-ID: <1126637123.12728.43.camel@state.g2switchworks.com> (raw)
In-Reply-To: <4326F406.7010402@gmail.com>
References: <KGEFLMPJFBNNLNOOOPLGOEOGCIAA.simon@2ndquadrant.com>
<4326F406.7010402@gmail.com>
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.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-general@postgresql.org
Cc: smarlowe@g2switchworks.com, pickscrape@gmail.com
Subject: Re: Replication
In-Reply-To: <1126637123.12728.43.camel@state.g2switchworks.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox