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
