On Fri, Mar 04, 2011 at 08:37:46AM -0600, Kenneth Marshall wrote: > On Thu, Mar 03, 2011 at 07:43:46PM -0800, Uwe Schroeder wrote: > > > > Did you read the paragraph above? > > > > Install latest version, and restart postmaster. > > > Installing of latest version as-is will keep overwriting the existing > > > installed directories/files/binaries but not the "/usr/local/pgsql/data/" > > > directory right? Since this is our production server database, am just > > > clarifying this question that came to my mind, before upgrading. > > For sake of safety, I'd always make a backup of the data > > directory. You don't need to dump/restore. Just copy the files > > someplace else and then do the update. In case something goes > > wrong you can always go back to your old version and just copy the > > backup to the data directory. > The "Just copy the files someplace else" can take a long, long > time for a large database and you need to have the database off-line > for the copy to be correct. Not really an option in many environments. You can use something like rsync quite effectively in this case. Take your first copy while the database is up. This moves the majority of the data. Then take down the database and re-sync. Rsync will move only the changed bits. Depending on how much of your data churns I have seen the second rsync take under a minute where the first one was running for 6 or so hours. The restore worked perfectly. Now if you have a multi TB db YMMV. An alternative is to do a PITR image backup. So tell postgres to start archiving wal logs as part of PIRT, backup the database cluster, tell postgres the backup is done, copy the archived wal logs to a safe spot. -- -- rouilj John Rouillard System Administrator Renesys Corporation 603-244-9084 (cell) 603-643-9300 x 111 -- Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin
