From: Bruce Momjian <bruce@momjian.us>
To: tsuraan <tsuraan@gmail.com>
Cc: pgsql-admin@postgresql.org
Subject: Re: Streaming replication upgrade sanity check
Date: Fri, 12 Mar 2021 14:47:08 -0500
Message-ID: <20210312194708.GB5362@momjian.us> (raw)
In-Reply-To: <CALKcMw+Y0HRFHY8uNS+VGKeFmbnCVJ02Az1YK4r6-_FnXgPDWg@mail.gmail.com>
References: <CALKcMwLoZajZ8_8OJefNgaCiaXa0MsbDFiiWN-nYyGD-9gAbiA@mail.gmail.com>
<20210312005016.GV20766@tamriel.snowman.net>
<20210312005557.GA2999@momjian.us>
<CALKcMw+Y0HRFHY8uNS+VGKeFmbnCVJ02Az1YK4r6-_FnXgPDWg@mail.gmail.com>
On Fri, Mar 12, 2021 at 10:53:11AM -0600, tsuraan wrote:
> > He/she wants to run the standby, I guess in read-only mode, while
> > pg_upgrade is running, which is why I didn't even bother to mention
> > that. I think if downtime is the critical for this person, he/she
> > should be using logical replication for the upgrade. pg_upgrade really
> > wants full control of the primary/standbys during its operation, and if
> > you can't do that, pg_upgrade is not the right tool to use.
>
> This thread blew up a bit overnight, so I guess I might be getting a
> bit repetitive, but it's less about super low downtime and more about
> just not having all that much control over everything. The systems are
> installed all over the world, and the upgrade process is very solid
> and well understood (by my client's devs), but it's pretty reliant on
> the main database being running, and also standby systems are fairly
> independent, so doing a lot of coordination is somewhere between
> complicated and maybe not entirely possible.
>
> I do just want to clarify the bit about pg_upgrade wanting full
> control over standbys. I'm looking over the page again, and it does
> list some prereqs to make sure things will run smoothly on the
> standby, but if I do just abandon the standby systems and do a new
> pg_basebackup on them once the master is running again, that's not
> going to cause any issues on the master, right? I haven't had any
> explosions in testing, but none of my test systems are anywhere near
> as large or busy as the larger customers, so I definitely could be
> missing things.
Right, just making new standbys is simple. The basic idea is that
pg_upgrade will complain about anything that isn't exactly as required,
to avoid invisible upgrade failures. When you started asking about
exactly how we could stretch pg_upgrade, we started to have to discuss
exactly what we could relax with 100% reliability, and we didn't come up
with many options. We are happy to continue that discussion but we
don't have any good ideas right now.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
The usefulness of a cup is in its emptiness, Bruce Lee
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: <20210312194708.GB5362@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