What we did in this kind of higher performance storage migration, setting up standby on that mounts and then executed a failover.
On Thu, Apr 3, 2014 at 3:58 PM, Alan Hodgson <ahodg...@simkin.ca> wrote: > On Thursday, April 03, 2014 02:48:03 PM Steven Schlansker wrote: > > On Apr 2, 2014, at 3:08 PM, Jacob Scott <jacob.sc...@gmail.com> wrote: > > * pg_start_backup > > * Take a filesystem snapshot (of a volume containing postgres data > but not > > pg_xlog) * pg_stop_backup > > * pg_ctl stop > > * Bring a new higher performing disk online from snapshot > > * switch disks (umount/remount at same mountpoint) > > * pg_ctl start > > ... with a recovery.conf in place when starting the new instance. > > > > > Assuming you ensure that your archived xlogs are available same to the > new > > instance as the old > > And make sure they're archived to a different disk. > > > Another option you could consider is rsync. I have often transferred > > databases by running rsync concurrently with the database to get a "dirty > > backup" of it. Then once the server is shutdown you run a cleanup rsync > > which is much faster than the initial run to ensure that the destination > > disk is consistent and up to date. This way your downtime is limited to > > how long it takes rsync to compare fs trees / fix the inconsistencies. > > > > This would be simpler. > > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general >
