Skip site navigation (1) Skip section navigation (2)

Re: Using pg_upgrade on log-shipping standby servers

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Aidan Van Dyk <aidan(at)highrise(dot)ca>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>,PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Using pg_upgrade on log-shipping standby servers
Date: 2012-07-20 17:11:11
Message-ID: 20120720171111.GA7060@momjian.us (view raw, whole thread or download thread mbox)
Thread:
Lists: pgsql-hackers
On Fri, Jul 20, 2012 at 12:39:12PM -0400, Aidan Van Dyk wrote:
> If you're wanting to automatically do some upgrades wouldn't an easier route be:
> 
> 1) run pg_upgrade, up to the point where it actually start's
> copying/linking in old cluster data files, and stop the new
> postmaster.
> 2) Take a "base backup" style copy (tar, rsync, $FAVOURITE) of the new
> cluster (small, since without data files)
> 3) Have pg_upgrade leave a log of exactly which old cluster data files
> go where in the new cluster
> 
> That way, anybody, any script, etc who wants to make a new "standby"
> from and old one only needs the pg_upgrade base backup (which should
> be small, no data, just catalog stuff), and the log of which old files
> to move where.
> 
> The only pre-condition is that the standby's "old pg" *APPLIED* WAL up
> to the exact same point as the master's "old pg".  In that case the
> standby's old cluster data files should same enough (maybe hint bits
> off?) to be used.

I am not sure what a base backup is buying us here --- base backup is
designed to create a backup while the server is running, and it is down
at that point.  I think what you are suggesting is to make a data dir
copy while just the schema is in place.  That is possible, but it opens
up all kinds of possible failure cases because pg_upgrade operations
have to be done in a specific order --- it feels very fragile.

I think the commands to run after pg_upgrade --link completes on both
primary and standby might be as easy as:

	cd /u/pg/pgsql.old/data
	find . -links 1 -exec cp {} /u/pgsql/data \;

Why would we want anything more complicated than this?

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2012-07-20 17:12:32
Subject: Re: Restrict ALTER FUNCTION CALLED ON NULL INPUT (was Re: Not quite a security hole: CREATE LANGUAGE for non-superusers)
Previous:From: Aidan Van DykDate: 2012-07-20 16:39:12
Subject: Re: Using pg_upgrade on log-shipping standby servers

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group