Re: Streaming replication upgrade sanity check

From: tsuraan <tsuraan(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Streaming replication upgrade sanity check
Date: 2021-03-12 16:38:23
Message-ID: CALKcMwKqbuErn4aZ2z4hJXPgjeiWHFvEP-EHJorRJ8yjAz6JOQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

> You don't need to go to 11 or 12 if you want to upgrade to 13- you can
> just pg_upgrade directly to 13.

That's cool. In that case, I assume I could also only have the old
(10.x) and the new 13.2 postgres versions installed? The intermediate
steps of calling pg_upgrade aren't a problem, but if I could skip
shipping out and installing postgres 11 and 12, that would be pretty
nice.

> Exactly how are you doing this rsync..? A simplistic rsync would end up
> just copying everything over and, as Bruce says later, if you're doing
> that then you might as well just use pg_basebackup or a similar tool to
> do it cleanly. In other words, I don't think that you're actually
> getting the benefit that you think you are with this.. Note that the
> file names are not kept the same after the pg_upgrade...

The exact rsync flags are "-acz" "--delete" (so, --archive --checksum
--compress --delete). I'm now seeing that I left off --hardlink, which
was definitely a mistake, but I also don't know whether --checksum is
a valid thing to do when the master is active. From the general tone
of this discussion, it may be "fine", but it's not likely to be better
than just doing a pg_basebackup, and of course pg_basebackup is
definitely correct. I want to do things efficiently, but doing them
correctly comes first, so I'll probably just go with a basebackup and
deal with complaints as they come in :)

> Also- I don't think you realize how fast the rsync process to update the
> standbys will be. Done correctly, it should be faster than the
> pg_upgrade.. Note that you'll want to make sure you TRUNCATE and
> unlogged tables before the pg_upgrade, et al, otherwise you'll end up
> rsync'ing those over. Also make sure you haven't got any stray or
> forgotten temp files or other things. Again, done properly, the rsync
> to upgrade the standbys should only be copying the catalog tables
> themselves and it should be quite fast.

Yeah, it's not as much a matter of how long a sync will take, but just
the way the systems fit together. The systems are all customer-owned,
running in customer locations, and we don't actually have a guarantee
that the standby targets are even powered up while the main database
is upgrading. They absolutely should be, but customer installations
can get pretty weird, so I'm going to stick with fully upgrading and
activating the master machines as quickly as possible, and then
dealing with getting the upgrades to the standby systems however I
have to. It's looking like a new pg_basebackup is just the best
approach given what I have to work with, so I'll switch to that unless
somebody stops me :)

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message tsuraan 2021-03-12 16:53:11 Re: Streaming replication upgrade sanity check
Previous Message Tilman Koschnick 2021-03-12 08:59:38 Re: applicable mapping for clientcert=verify-full