pg.ddx.io  pgsql-admin@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Bruce Momjian <bruce@momjian.us>
To: tsuraan <tsuraan@gmail.com>
Cc: pgsql-admin@postgresql.org
Subject: Re: Streaming replication upgrade sanity check
Date: Wed, 10 Mar 2021 21:22:32 -0500
Message-ID: <20210311022232.GA11270@momjian.us> (raw)
In-Reply-To: <CALKcMwLoZajZ8_8OJefNgaCiaXa0MsbDFiiWN-nYyGD-9gAbiA@mail.gmail.com>
References: <CALKcMwLoZajZ8_8OJefNgaCiaXa0MsbDFiiWN-nYyGD-9gAbiA@mail.gmail.com>

On Sat, Feb 13, 2021 at 10:02:20AM -0600, tsuraan wrote:
> I have several streaming replication pairs running under postgres 10,
> and I'm looking at upgrading them to postgres 13. Doing that on the
> active side is pretty quick and easy: just run pg_upgrade once for
> each of versions 11, 12, and 13, then start things up again. That's
> tested (on non-replicated instances) and seems to be working great.
> The standby side looks a little bit more interesting, so I wanted some
> feedback about whether my approach looks safe.
> 
> It looks like the most correct approach would be to discard the
> standby systems and just do a new pg_basebackup, but quite a few of
> the pairs have a standby on AWS and limited upstream bandwidth, so the
> basebackup can take several days. I'd like to avoid that if I can.
> 
> So, my thought is to just upgrade the active side as normal, and once
> that's done and the master is back in use, stop the standby's
> postgres, call "pg_start_backup(...)" on the master, rsync the changed
> files from the running master's data dir to the standby's 10.x data
> directory, call "pg_stop_backup()", migrate the recovery.conf into a
> postgresql.auto.conf, touch the standby.signal file, and then start
> the new postgres 13 on the standby. That seems to work, but I want to
> be sure I'm not just having good luck due to the relatively low
> activity on my test systems.
> 
> I use named replication slots with my streaming replication, so I
> think that the rsync'd pg_wal directory should have everything I need
> (or maybe this isn't guaranteed?), and the pg_start/stop_backup will
> ensure that all the damage done by rsync'ing an active database can be
> repaired from the pg_wal files that rsync fetches. Are those
> assumptions right, or am I missing anything else? Is this idea
> workable at all?

Did you see the pg_upgrade instructions on upgrading standby servers? 
Why are you not using that?

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  The usefulness of a cup is in its emptiness, Bruce Lee






view thread (12+ messages)  latest in thread

Message-ID: <20210311022232.GA11270@momjian.us>
Permalink:  ../20210311022232.GA11270@momjian.us/
Also on:    postgresql.org/message-id/20210311022232.GA11270@momjian.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-admin@postgresql.org
  Cc: bruce@momjian.us, tsuraan@gmail.com
  Subject: Re: Streaming replication upgrade sanity check
  In-Reply-To: <20210311022232.GA11270@momjian.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox