On Tue, Nov 1, 2011 at 11:08 AM, Alan Hodgson <ahodgson@simkin.ca> wrote:
> On October 31, 2011 03:01:19 PM Stephen Denne wrote:
>> I'm wondering whether it's worth doing anyway, simply to check that it
>> doesn't do something completely unexpected, which would presumably alert
>> us to something we hadn't considered.
>>
>
> Testing is always worthwhile, if only to ensure that PostgreSQL will actually
> run with your configuration on the new machine (sufficient shared memory, IP
> addresses specified in postgresql.conf, etc).
>
> However, assuming the PostgreSQL binary packages you're using are identical,
> and assuming that you aren't changing tablespace pointers around, the rsync /
> restart is pretty fool-proof in terms of reliably copying PostgreSQL itself.
> PostgreSQL is good about updating time stamps on modified files, you don't have
> to worry about needing the full compare options on rsync or anything "-avr --
> delete" is generally sufficient .
>
> You might disable WAL archiving during a test startup to avoid sending
> duplicates to your backup server.
>
You know, this looks like it will work, but if I were you, I would set
up the database as a PITR standby on the new box, and have WAL
shipping in place. When you're ready to move, you shutdown the old
database, synch up the xlogs, and then failover to the new database.
Not only should this be faster, it seems less error prone, and you can
actually test the failover and lunch bits while the original server is
up and running.
Robert Treat
conjecture: xzilla.net
consulting: omniti.com