On Thu, Oct 25, 2012 at 9:47 AM, Shaun Thomas <sthomas@xxxxxxxxxxxxxxxx> wrote:
>> ... as long as the rsync was bracketed by calls to pg_start_backup()
>> and pg_stop_backup().
>
>
> Or they took it during a filesystem snapshot, or shut the database down.
>
> I thought that the only thing start/stop backup did was mark the beginning
> and end transaction logs for the duration of the backup so they could be
> backed up separately for a minimal replay.
>
> An rsync doesn't need that, because it's binary compatible. You get two
> exact copies of the database, provided data wasn't changing. That's easy
> enough to accomplish, really.
... as long as the rsync was bracketed by calls to pg_start_backup()
and pg_stop_backup().
Or they took it during a filesystem snapshot, or shut the database down.
I thought that the only thing start/stop backup did was mark the
beginning and end transaction logs for the duration of the backup so
they could be backed up separately for a minimal replay.
An rsync doesn't need that, because it's binary compatible. You get
two exact copies of the database, provided data wasn't changing.
That's easy enough to accomplish, really.
Well, that's the thing. Without pg_start_backup, the database is
changing and rsync will not make a perfect copy. With pg_start_backup,
the replica will replay the WAL from the start_backup point, and any
difference rsync left will be ironed out.
That's why I say:
rsync - the first one takes a long time
start backup
rsync - this one will take a lot less
stop backup
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
