From: | Nikolay Samokhvalov <nik(at)postgres(dot)ai> |
---|---|
To: | Stephen Frost <sfrost(at)snowman(dot)net> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
Subject: | Re: pg_upgrade instructions involving "rsync --size-only" might lead to standby corruption? |
Date: | 2023-07-10 20:36:39 |
Message-ID: | CAM527d_-YmKqFfJmnPsVSeqKC_WHoJVQwxtNvUiV4ju+9stDpA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 7, 2023 at 6:31 AM Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Nikolay Samokhvalov (nik(at)postgres(dot)ai) wrote:
> > But this can happen with anyone who follows the procedure from the docs
> as
> > is and doesn't do any additional steps, because in step 9 "Prepare for
> > standby server upgrades":
> >
> > 1) there is no requirement to follow specific order to shut down the
> nodes
> > - "Streaming replication and log-shipping standby servers can remain
> > running until a later step" should probably be changed to a
> > requirement-like "keep them running"
>
> Agreed that it would be good to clarify that the primary should be shut
> down first, to make sure everything written by the primary has been
> replicated to all of the replicas.
>
Thanks!
Here is a patch to fix the existing procedure description.
I agree with Andrey – without it, we don't have any good way to upgrade
large clusters in short time. Default rsync mode (without "--size-only")
takes a lot of time too, if the load is heavy.
With these adjustments, can "rsync --size-only" remain in the docs as the
*fast* and safe method to upgrade standbys, or there are still some
concerns related to corruption risks?
Attachment | Content-Type | Size |
---|---|---|
pg-upgrade-docs-clarify-rsync-size-only.patch | application/octet-stream | 3.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Joseph Koshakow | 2023-07-10 20:46:07 | Re: Preventing non-superusers from altering session authorization |
Previous Message | Nathan Bossart | 2023-07-10 20:31:58 | Re: Preventing non-superusers from altering session authorization |