MIME-Version: 1.0
References: <CAD=40Z3Rvbx46SxYBBdLvgSObXCP+Firszz++rDTXmGX795D2Q@mail.gmail.com>
 <6c498f0e-64f9-449a-9b90-5cd72d00e2ef@aklaver.com> <CAD=40Z1wJ7mBej9=Yqfo_1m-eOV61E=s6yDjZSaTBESbGunBUA@mail.gmail.com>
 <2a7d96ac-83a7-4ddc-a3ce-9c637f2c1c76@aklaver.com> <CAD=40Z3prwhLAedetocCu3jFvHSBP44V6O9d6CXjvzLTw7eOUQ@mail.gmail.com>
 <CANzqJaACBw1=jCAxGwSeu7dh4UfD2KePcNqSOC3=WwzXrg0skQ@mail.gmail.com>
In-Reply-To: <CANzqJaACBw1=jCAxGwSeu7dh4UfD2KePcNqSOC3=WwzXrg0skQ@mail.gmail.com>
From: Subhash Udata <subhashudata@gmail.com>
Date: Sun, 24 Nov 2024 22:33:58 +0530
Message-ID: <CAD=40Z3k2dgVidM3oYuMWsauHyKF9v-0i4nOfMXd917PtNiO_g@mail.gmail.com>
Subject: Re: Questions on Upgrading PostgreSQL from 15.0 to 15.9 and Setting
 Up Streaming Replication
To: Ron Johnson <ronljohnsonjr@gmail.com>
Cc: pgsql-general <pgsql-general@postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000be662a0627ab9a7b"
Archived-At: <https://www.postgresql.org/message-id/CAD%3D40Z3k2dgVidM3oYuMWsauHyKF9v-0i4nOfMXd917PtNiO_g%40mail.gmail.com>
Precedence: bulk

--000000000000be662a0627ab9a7b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Thank you for your valuable suggestion!

I have a question regarding the process:
When we shut down the standby, upgrade it, and then start it back up, will
the replication automatically resume from the primary to the standby?

Looking forward to your clarification.

2) What do you mean by resource-intensive?  If it means network bandwidth,
then read the pg_basebackup man page.
  No, it=E2=80=99s not about pg_basebackup consuming resources. What I mean=
t is
that in the event of a failover, if we need to bring the standby back
online, the process of running pg_basebackup takes a significant amount of
time. However, if using a cron job for this purpose is a viable option,
then that would be acceptable.


On Sun, 24 Nov 2024 at 22:27, Ron Johnson <ronljohnsonjr@gmail.com> wrote:

> On Sun, Nov 24, 2024 at 11:52=E2=80=AFAM Subhash Udata <subhashudata@gmai=
l.com>
> wrote:
>
>> I understand your point and appreciate the clarification.
>>
>> I have reviewed the references and now have a better understanding of th=
e
>> minor upgrade process.
>>
>> However, my concern lies in the fact that we are working with production
>> servers, where downtime is not acceptable.
>>
>> Additionally, if a failover occurs due to a network issue or any other
>> disaster, setting up replication again requires running the pg_basebacku=
p
>> command. For large databases, this process becomes a significant challen=
ge,
>> as running pg_basebackup for the entire cluster can be time-consuming
>> and resource-intensive.
>>
>
> A comment and a question:
> 1) pg_basebackup runs just fine from cron.  Thus, "time-consuming" (which
> you described as 2-3 hours) isn't that critical.
> 2) What do you mean by resource-intensive?  If it means network bandwidth=
,
> then read the pg_basebackup man page.
>
> --
> Death to <Redacted>, and butter sauce.
> Don't boil me, I'm still alive.
> <Redacted> lobster!
>

--000000000000be662a0627ab9a7b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>Thank you for your valuable suggestion!</p><p>I have a =
question regarding the process:<br>When we shut down the standby, upgrade i=
t, and then start it back up, will the replication automatically resume fro=
m the primary to the standby?<br><br>Looking forward to your clarification.=
<br><br>2) What do you mean by resource-intensive?=C2=A0 If it means networ=
k bandwidth, then read the pg_basebackup man page.<br>=C2=A0 No, it=E2=80=
=99s not about <code>pg_basebackup</code> consuming resources. What I meant=
 is that in the event of a failover, if we need to bring the standby back o=
nline, the process of running <code>pg_basebackup</code> takes a significan=
t amount of time. However, if using a cron job for this purpose is a viable=
 option, then that would be acceptable.=C2=A0=C2=A0</p><p><br></p></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, 2=
4 Nov 2024 at 22:27, Ron Johnson &lt;<a href=3D"mailto:ronljohnsonjr@gmail.=
com">ronljohnsonjr@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204=
,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr">On Sun, Nov 2=
4, 2024 at 11:52=E2=80=AFAM Subhash Udata &lt;<a href=3D"mailto:subhashudat=
a@gmail.com" target=3D"_blank">subhashudata@gmail.com</a>&gt; wrote:</div><=
div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr"><div dir=3D"ltr"><p>I understand your point and appreciat=
e the clarification.</p><p>I have reviewed the references and now have a be=
tter understanding of the minor upgrade process.</p><p>However, my concern =
lies in the fact that we are working with production servers, where downtim=
e is not acceptable.</p><p>Additionally, if a failover occurs due to a netw=
ork issue or any other disaster, setting up replication again requires runn=
ing the <code>pg_basebackup</code> command. For large databases, this proce=
ss becomes a significant challenge, as running <code>pg_basebackup</code> f=
or the entire cluster can be time-consuming and resource-intensive.</p></di=
v></div></blockquote><div><br></div><div>A comment and a question:</div><di=
v></div></div><div>1) pg_basebackup runs just fine from cron.=C2=A0 Thus, &=
quot;time-consuming&quot; (which you described as 2-3 hours) isn&#39;t that=
 critical.</div><div>2) What do you mean by resource-intensive?=C2=A0 If it=
 means network bandwidth, then read the pg_basebackup man page.</div><div><=
br></div><span class=3D"gmail_signature_prefix">-- </span><br><div dir=3D"l=
tr" class=3D"gmail_signature"><div dir=3D"ltr">Death to &lt;Redacted&gt;, a=
nd butter sauce.<div>Don&#39;t boil me, I&#39;m still alive.<br><div><div>&=
lt;Redacted&gt; lobster!</div></div></div></div></div></div>
</blockquote></div>

--000000000000be662a0627ab9a7b--