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

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>
Cc: David Gibbons <david(at)dgibbons(dot)net>, Patrick B <patrickbakerbr(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: 2.5TB Migration from SATA to SSD disks - PostgreSQL 9.2
Date: 2016-09-08 13:04:25
Message-ID: CAOR=d=0FO4bFYN2KGOr_o3A31S7P3LRbmhkZaKfNkE1-M1TFyQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Wed, Sep 7, 2016 at 5:00 PM, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2016-09-08 13:09:08 Re: Postgres UPGRADE from 9.2 to 9.4
Previous Message Martijn Tonies (Upscene Productions) 2016-09-08 11:51:49 Re: IDE for function/stored proc development.