From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com> |
Subject: | Re: pg_upgrade and rsync |
Date: | 2015-01-28 02:32:08 |
Message-ID: | 20150128023208.GB31346@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jan 26, 2015 at 05:41:59PM -0500, Stephen Frost wrote:
> I've thought about it a fair bit actually and I agree that there is some
> risk to using rsync for *incremental* base backups. That is, you have
> a setup where you loop with:
>
> pg_start_backup
> rsync -> dest
> pg_stop_backup
>
> without using -I, changing what 'dest' is, or making sure it's empty
> every time. The problem is the 1s-level granularity used on the
> timestamp. A possible set of operations, all within 1s, is:
>
> file changed
> rsync starts copying the file
> file changed again (somewhere prior to where rsync is at)
> rsync finishes the file copy
>
> Now, this isn't actually a problem for the first time that file is
> backed up- the issue is if that file isn't changed again. rsync won't
> re-copy it, but that change that rsync missed won't be in the WAL
> history for the *second* backup that's done (only the first), leading to
> a case where that file would end up corrupted.
Interesting problem, but doesn't rsync use sub-second accuracy?
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2015-01-28 02:41:15 | Re: pg_upgrade and rsync |
Previous Message | Robert Haas | 2015-01-28 02:16:41 | Re: Parallel Seq Scan |