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

From Patrick B
Subject Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2
Date
Msg-id CAJNY3itCsDKbaPov3bg2pFmAsX4YV1hZT=oc6q__mzcy8WrEYQ@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>)
List pgsql-general


2016-09-08 11:49 GMT+12:00 Jim Nasby <Jim.Nasby@bluetreble.com>:
Please include the mailing list in replies...

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!

Cool! I'll use the rsync -va --modify-window=1 instead.

Thanks!
Patrick 

pgsql-general by date:

Previous
From: Jim Nasby
Date:
Subject: Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2
Next
From: "dandl"
Date:
Subject: Re: What limits Postgres performance when the whole database lives in cache?