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 по дате отправления: