MIME-Version: 1.0
References: <CAAccyYKpNsQMD+S-A7a8YtDevFN0uRXkzg4tYWWBOFsv_jASNg@mail.gmail.com>
 <CAKAnmmJPGgEp2kKPomhq7P=GUA5HD1eOaP5X+7c68gm5f4YVqQ@mail.gmail.com>
In-Reply-To: <CAKAnmmJPGgEp2kKPomhq7P=GUA5HD1eOaP5X+7c68gm5f4YVqQ@mail.gmail.com>
From: px shi <spxlyy123@gmail.com>
Date: Tue, 12 Aug 2025 16:33:48 +0800
Message-ID: <CAAccyYL1tE956RWaRrP-2a-Z+TBhsUi3QS+qO_BXjiHnNcFgog@mail.gmail.com>
Subject: Re: Questions about the continuity of WAL archiving
To: Greg Sabino Mullane <htamfids@gmail.com>
Cc: pgsql-general@lists.postgresql.org
Content-Type: multipart/alternative; boundary="000000000000e42e35063c26e66c"
Archived-At: <https://www.postgresql.org/message-id/CAAccyYL1tE956RWaRrP-2a-Z%2BTBhsUi3QS%2BqO_BXjiHnNcFgog%40mail.gmail.com>
Precedence: bulk

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

>
> I'm still not clear on what the problem here is, other than your archivin=
g
> not keeping up.

 In my scenario, archive_mode is not set to always on the replicas, it may
cause interruptions in the archived WAL logs.

You can set archive_mode=3Dalways on the replicas to help with this.

Yes, it can work. And I would like to know if this is the recommended
configuration for production use?

Greg Sabino Mullane <htamfids@gmail.com> =E4=BA=8E2025=E5=B9=B48=E6=9C=889=
=E6=97=A5=E5=91=A8=E5=85=AD 02:25=E5=86=99=E9=81=93=EF=BC=9A

> There is a scenario: the current timeline of the PostgreSQL primary node
>> is 1, and the latest WAL file is 100. The standby node has also received=
 up
>> to WAL file 100. However, the latest WAL file archived is only file 80. =
If
>> the primary node crashes at this point and the standby is promoted to th=
e
>> new primary, archiving will resume from file 100 on timeline 2. As a
>> result, WAL files from 81 to 100 on timeline 1 will be missing from the
>> archive.
>> Is there a good solution to prevent this situation?
>>
>
> I'm still not clear on what the problem here is, other than your archivin=
g
> not keeping up. The best solution to that is:
>
>
> https://pgbackrest.org/1/configuration.html#section-archive/option-archiv=
e-async
>
> Yes, you would lost some ability for easy PITR for 80-100, but could stil=
l
> be done by resurrecting your crashed primary, or carefully grabbing from
> the replica before they get recycled. You can set archive_mode=3Dalways o=
n
> the replicas to help with this.
>
> Cheers,
> Greg
>
> --
> Crunchy Data - https://www.crunchydata.com
> Enterprise Postgres Software Products & Tech Support
>
>

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:r=
gb(204,204,204);padding-left:1ex">I&#39;m still not clear on what the probl=
em here is, other than your archiving not keeping up.</blockquote><div>=C2=
=A0In my scenario, archive_mode is not set to always on the replicas,=C2=A0=
it may cause interruptions in the archived WAL logs.<br></div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204)=
;padding-left:1ex">You can set archive_mode=3Dalways on the replicas to hel=
p with this.</blockquote><div>Yes, it can work. And I would like to know if=
 this is the recommended configuration for production use?</div></div><br><=
div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"g=
mail_attr">Greg Sabino Mullane &lt;<a href=3D"mailto:htamfids@gmail.com">ht=
amfids@gmail.com</a>&gt; =E4=BA=8E2025=E5=B9=B48=E6=9C=889=E6=97=A5=E5=91=
=A8=E5=85=AD 02:25=E5=86=99=E9=81=93=EF=BC=9A<br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;borde=
r-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:s=
olid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
<div>There is a scenario: the current timeline of the PostgreSQL primary no=
de is 1, and the latest WAL file is 100. The standby node has also received=
 up to WAL file 100. However, the latest WAL file archived is only file 80.=
 If the primary node crashes at this point and the standby is promoted to t=
he new primary, archiving will resume from file 100 on timeline 2. As a res=
ult, WAL files from 81 to 100 on timeline 1 will be missing from the archiv=
e.<br>Is there a good solution to prevent this situation?</div></div></bloc=
kquote><div><br></div><div>I&#39;m still not clear on what the problem here=
 is, other than your archiving not keeping up. The best solution to that is=
:</div><div><br></div><div><a href=3D"https://pgbackrest.org/1/configuratio=
n.html#section-archive/option-archive-async" target=3D"_blank">https://pgba=
ckrest.org/1/configuration.html#section-archive/option-archive-async</a></d=
iv><div><br></div><div>Yes, you would lost some ability for easy PITR for 8=
0-100, but could still be done by resurrecting your crashed primary, or car=
efully grabbing from the replica before they get recycled. You can set arch=
ive_mode=3Dalways on the replicas to help with this.</div><div>=C2=A0</div>=
</div><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><div>Chee=
rs,</div><div>Greg</div><div><br></div><div>--</div><div>Crunchy Data - <a =
href=3D"https://www.crunchydata.com" target=3D"_blank">https://www.crunchyd=
ata.com</a></div><div>Enterprise Postgres Software Products &amp; Tech Supp=
ort</div><div><br></div></div></div></div>
</blockquote></div>

--000000000000e42e35063c26e66c--