Re: pg_upgrade and rsync - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade and rsync
Date
Msg-id 20150220144508.GA20442@momjian.us
Whole thread Raw
In response to Re: pg_upgrade and rsync  (David Steele <david@pgmasters.net>)
Responses Re: pg_upgrade and rsync
List pgsql-hackers
On Thu, Feb 19, 2015 at 09:35:02PM -0500, David Steele wrote:
> On 2/19/15 11:57 AM, Bruce Momjian wrote:
> > On Wed, Jan 28, 2015 at 09:26:11PM -0800, Josh Berkus wrote:
> >>
> >> 3. Check that the replica is not very lagged.  If it is, wait for
> >> traffic to die down and for it to catch up.
> > 
> > Now that 9.4.1 is released, I would like to get this doc patch applied
> > --- it will close the often-requested feature of how to pg_upgrade slave
> > clusters.
> > 
> > I wasn't happy with Josh's specification above that the "replica is not
> > very lagged", so I added a bullet point to check the pg_controldata
> > output to verify that the primary and standby servers are synchronized.
> > 
> > Yes, this adds even more complication to the pg_upgrade instructions,
> > but it is really more of the same complexity.  pg_upgrade really needs
> > an install-aware and OS-aware tool on top of it to automate much of
> > this.
> 
> #3 bothered me as well because it was not specific enough.  I like what
> you've added to clarify the procedure.

Good.  It took me a while to understand why they have to be in sync ---
because we are using rsync in size-only-comparison mode, if they are not
in sync we might update some files whose sizes changed, but not others,
and the old slave would be broken.  The new slave is going to get all
new files or hard links for user files, so it would be fine, but we
should be able to fall back to the old slaves, and having them in sync
allows that.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Parallel Seq Scan
Next
From: Alvaro Herrera
Date:
Subject: Re: REVIEW: Track TRUNCATE via pgstat