Обсуждение: How to upgrade PostgreSQL minor releases without a dump/restore?

Hi,

Our production server is running PostgreSQL v8.2.3 on CentOS5.2. We're
planning to upgrade to the latest version in 8.2 series, that is v8.2.20.
Also, in future, we've planned to upgrade to the most recent minor release
as soon as possible (as and when released by PostgreSQL).

Initially, we've installed v8.2.3 from source. PostgreSQL is installed in
/usr/local/pgsql/ and data directory is available in /usr/local/pgsql/data

PostgreSQL Versioning policy says: "Upgrading to a minor release does not
require a dump and restore; merely stop the database server, install the
updated binaries, and restart the server."

Now, without a dump/restore, what are the recommended ways/steps involved in
upgrading PostgreSQL to latest version for minor releases?

Regards,
Gnanam

On Tue, 2011-03-01 at 13:23 +0530, Gnanakumar wrote:
>
> PostgreSQL Versioning policy says: "Upgrading to a minor release does
> not require a dump and restore; merely stop the database server,
> install the updated binaries, and restart the server."
>
> Now, without a dump/restore, what are the recommended ways/steps
> involved in upgrading PostgreSQL to latest version for minor releases?

? Did you read the paragraph above?

Install latest version, and restart postmaster.
--
Devrim GÜNDÜZ
Principal Systems Engineer @ EnterpriseDB: http://www.enterprisedb.com
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org  Twitter: http://twitter.com/devrimgunduz

On Mar 1, 2011, at 1:23 PM, Gnanakumar wrote:

>
> PostgreSQL Versioning policy says: "Upgrading to a minor release does not
> require a dump and restore; merely stop the database server, install the
> updated binaries, and restart the server."

Install the Binaries of Specific Minor Release and Start the PG Instance using new Binary (pg_ctl) of PG.

1. Stop PG using pg_ctl of v8.2.3.
2. Install v8.2.20
3. Start PG using v8.2.20 Binary.

Thanks & Regards,
Vibhor
Blog:http://vibhork.blogspot.com

> ? 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
questionthat came to my mind, before upgrading. 

> > ? 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.

That's how I do upgrades. Never needed the backup, but better to have one.

Uwe

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.
>
> That's how I do upgrades. Never needed the backup, but better to have one.
>
> Uwe
>
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.

Cheers,
Ken

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