Re: [GENERAL] Is it safe to stop postgres in between pg_start_backup and pg_stop_backup?
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 wrote: > On Thursday, April 03, 2014 02:48:03 PM Steven Schlansker wrote: > > On Apr 2, 2014, at 3:08 PM, Jacob Scott 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 >
Re: [GENERAL] Is it safe to stop postgres in between pg_start_backup and pg_stop_backup?
On Thursday, April 03, 2014 02:48:03 PM Steven Schlansker wrote: > On Apr 2, 2014, at 3:08 PM, Jacob Scott 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
Re: [GENERAL] Is it safe to stop postgres in between pg_start_backup and pg_stop_backup?
On Apr 2, 2014, at 3:08 PM, Jacob Scott wrote: > Hi, Hello there ;) > > > Does upgrading a a disk being used by postgres (9.1, on Ubuntu) with the > following process sound safe? > • pg_start_backup > • Take a filesystem snapshot (of a volume containing postgres data but > not pg_xlog) > • Bring a new higher performing disk online from snapshot > • pg_ctl stop > • switch disks (umount/remount at same mountpoint) > • pg_ctl start > • pg_stop_backup > This seems like an odd use case because pg_start_backup is designed for > performing on-line backups, but I think it will give me minimum downtime. At the very least you need to move your pg_stop_backup earlier in the process. Online backups do not survive server shutdowns; any backup in process at shutdown is aborted. • 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 Assuming you ensure that your archived xlogs are available same to the new instance as the old, I believe this should work. But run it on a test instance first! It sounds like an odd use case but really it’s no different from “the data is gone, restore from backup” — just that you intentionally trashed the data by switching disks :) 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. Good luck! -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
[GENERAL] Is it safe to stop postgres in between pg_start_backup and pg_stop_backup?
Hi, Does upgrading a a disk being used by postgres (9.1, on Ubuntu) with the following process sound safe? 1. pg_start_backup 2. Take a filesystem snapshot (of a volume containing postgres data but not pg_xlog) 3. Bring a new higher performing disk online from snapshot 4. pg_ctl stop 5. switch disks (umount/remount at same mountpoint) 6. pg_ctl start 7. pg_stop_backup This seems like an odd use case because pg_start_backup is designed for performing on-line backups, but I think it will give me minimum downtime. Thanks, Jacob
