Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2 - Mailing list pgsql-general

From Jeff Janes
Subject Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2
Date
Msg-id CAMkU=1whJm2oLi2z6TWVDucLeX=Wx9SzgbiRfv_koPE3-+crnw@mail.gmail.com
Whole thread Raw
In response to Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2  (David Gibbons <david@dgibbons.net>)
List pgsql-general
On Wed, Sep 7, 2016 at 4:49 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
On 9/7/16 6:10 PM, David Gibbons wrote:
    That is NOT safe. The problem is it allows rsync to use mtime alone
    to decide that a file is in sync, and that will fail if Postgres
    writes to a file in the same second that the first rsync reads from
    it (assuming Postgres writes after rsync reads). You need to add the
    --checksum flag to rsync (which means it will still have to read
    everything that's in /var/lib/pgsql).


The checksum flag as you mention is not performant,

Definitely not. :/

If this is a concern, you're much better using the *--modify-window *flag:
When comparing two timestamps, rsync treats the timestamps as being
equal if they differ by no more than the modify-window value. This is
normally 0 (for an exact match), but you may find it useful to set this
to a larger value in some situations.

Hence, rsync -va --modify-window=1 would remove your concern about a
same second race condition without forcing the sync to read through all
the files.

Very interesting and useful!

Isn't this heading in the wrong direction?   We need to be more precise than 0 (since 0 is computed off of rounded/truncated time stamps), not less precise than 0.

Cheers,

Jeff

pgsql-general by date:

Previous
From: Ken Tanzer
Date:
Subject: Re: How to assemble all fields of (any) view into a string?
Next
From: David Gibbons
Date:
Subject: Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2