If something was wrong with the cluster, why did vacuumdb on new server run successfully when I followed Craig's suggestion of running vacuumdb on old server first, before performing the upgrade, and then ran vacuumdb on new one?
On Fri, Jul 6, 2012 at 4:05 PM, Bruce Momjian <br...@momjian.us> wrote: > On Fri, Jul 06, 2012 at 04:03:38PM -0400, Payal Singh wrote: > > The omnipitr-backup-slave process takes online backups from the standby, > and > > this is done everyday. This process connects to the master and calls a > > pg_start_backup and then looks for a restore point on the standby after > that > > WAL address. So i don't think I need to shut down the server. > > My guess is if you try pg_upgrade without omnipitr-backup-slave, and it > works, odds are something about your use of omnipitr-backup-slave is > wrong. > > > Also, it is the omnipitr-backup-slave process that makes a separate > backup for > > xlog. > > > > > > If you run vacuumedb now, does everything later work fine? > > > > > > I'm not sure about that. Didn't try anything else after that. The > 9.2beta2 > > server starts without errors though. > > True, but it seems like something it wrong about the cluster, as is > shown by vacuumdb. > > --------------------------------------------------------------------------- > > > > > > Regards, > > Payal > > > > On Fri, Jul 6, 2012 at 3:30 PM, Bruce Momjian <br...@momjian.us> wrote: > > > > On Fri, Jul 06, 2012 at 02:22:28PM -0400, Payal Singh wrote: > > > The first message in the log is probably because the backup is > taken from > > a > > > standby. I am using omnipitr-backup-slave to make the backups and > then > > > restoring one of those. > > > > OK, this is what I wanted to see. Is the server running while you > are > > taking these backups, because that will not work. > > > > > The whole process that I followed is: > > > > > > > > > 1. Restoring backup file: > > > 2. > > > 3. payal@sparedb1:/data/pg$ sudo tar -xvzf > /mnt/nas/backups/postgres/ > > > userslave2/backups/data/ > > userslave2.int.functionx.net-xlog-2012-07-03.tar.gz > > > > > 489. payal@sparedb1:/data/pg$ sudo tar -xvzf > /mnt/nas/backups/postgres/ > > > userslave2/backups/data/ > > userslave2.int.functionx.net-xlog-2012-07-03.tar.gz > > > 490. 9.1/pg_xlog/ > > > 491. 9.1/pg_xlog/000000010000027C00000070 > > > 492. 9.1/pg_xlog/000000010000027C0000006B.009707C0.backup > > > 493. 9.1/pg_xlog/000000010000027C0000006D > > > 494. 9.1/pg_xlog/000000010000027C0000006C > > > 495. 9.1/pg_xlog/000000010000027C0000006B > > > 496. 9.1/pg_xlog/000000010000027C0000006E > > > 497. 9.1/pg_xlog/000000010000027C00000071 > > > 498. 9.1/pg_xlog/000000010000027C0000006F > > > > Why is the xlog backup a separate step? Because it is a separate > file > > system? The system is down, I assume. > > > > If you run vacuumedb now, does everything later work fine? > > > > -- > > Bruce Momjian <br...@momjian.us> http://momjian.us > > EnterpriseDB http://enterprisedb.com > > > > + It's impossible for everything to be true. + > > > > > > > > > > -- > > Payal Singh > > Graduate Student > > Department of Computer Science and Electrical Engineering > > University of Maryland, Baltimore County > > -- > Bruce Momjian <br...@momjian.us> http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + > -- Payal Singh Graduate Student Department of Computer Science and Electrical Engineering University of Maryland, Baltimore County
