Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2
Дата
Msg-id CAMkU=1whJm2oLi2z6TWVDucLeX=Wx9SzgbiRfv_koPE3-+crnw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2  (David Gibbons <david@dgibbons.net>)
Список 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 по дате отправления:

Предыдущее
От: Ken Tanzer
Дата:
Сообщение: Re: How to assemble all fields of (any) view into a string?
Следующее
От: David Gibbons
Дата:
Сообщение: Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2