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

Поиск
Список
Период
Сортировка
От Scott Marlowe
Тема Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2
Дата
Msg-id CAOR=d=0FO4bFYN2KGOr_o3A31S7P3LRbmhkZaKfNkE1-M1TFyQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-general
On Wed, Sep 7, 2016 at 5:00 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 9/2/16 11:44 AM, David Gibbons wrote:
>>
>> rsync -va /var/lib/pgsql/ /var/lib/pgsql2/
>> service postgres stop
>> rsync -va /var/lib/pgsql/ /var/lib/pgsql2/
>>
>> The second rsync will only copy the deltas from the first, it still has
>> to go in and determine what needs to be copied/what changed but the bulk
>> of it can be prepared/migrated before the actual downtime window.
>
>
> 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).
> --

I'm still wondering why my advice to just subscribe a new cluster on
the master machine was just ignored by OP. Postgresql already has a
pretty reliable method for doing what the OP wants using
pg_basebackup. Using rsync etc is like reinventing the wheel imho.

--
To understand recursion, one must first understand recursion.


В списке pgsql-general по дате отправления:

Предыдущее
От: "Martijn Tonies \(Upscene Productions\)"
Дата:
Сообщение: Re: IDE for function/stored proc development.
Следующее
От: Scott Marlowe
Дата:
Сообщение: Re: Postgres UPGRADE from 9.2 to 9.4