public inbox for [email protected]
help / color / mirror / Atom feedFrom: Ron Johnson <[email protected]>
To: pgsql-generallists.postgresql.org <[email protected]>
Subject: Re: Questions about the continuity of WAL archiving
Date: Tue, 12 Aug 2025 22:10:50 -0400
Message-ID: <CANzqJaD-pOt=0CBFXUPEXMtD8AMi_y76z4=Rak405+Rhui4hKQ@mail.gmail.com> (raw)
In-Reply-To: <CAAccyYLdp7AkqS9or3cc+=HSBo3bWMojR20KkzWSC5BenEn=VQ@mail.gmail.com>
References: <CAAccyYKpNsQMD+S-A7a8YtDevFN0uRXkzg4tYWWBOFsv_jASNg@mail.gmail.com>
<[email protected]>
<CAAccyYLYZmwQiNMoJcQgo5t+E24rDtu1ZeBUrER7ZTKNAcZesw@mail.gmail.com>
<[email protected]>
<CAAccyYJ-07SzCRAEkGJ2Qa8EAPCHQM4qcpB=OvD8P0zDbCJ0KQ@mail.gmail.com>
<[email protected]>
<CAAccyYLdp7AkqS9or3cc+=HSBo3bWMojR20KkzWSC5BenEn=VQ@mail.gmail.com>
How often does your primary node crash, and then not recover due to WALs
corruption or WALs not existing?
If it's _ever_ happened, you should _fix that_ instead of rolling your own
WAL archival.process.
On Tue, Aug 12, 2025 at 10:05 PM px shi <[email protected]> wrote:
> Hi, Adrian
>
> Given that you are using a less then capable storage solution(S3) why do
>> you think pushing the WAL from the standby to S3 would perform any
>> better then what is happening with the primary WAL?
>>
>
> I mean that archive_mode is set to on in primary and set to always in
> standby.
> This way, even if the primary crashes, the standby can still archive WAL
> files that the primary did not archive.
>
> The solution is to use a more capable storage platform.
>>
>
> However, I believe that even if we use a more capable storage platform,
> it is still impossible to archive WAL files in real time. As long as
> real-time archiving cannot be achieved, there will always be some WAL files
> that are not archived if the primary node crashes.
>
> Adrian Klaver <[email protected]> 于2025年8月13日周三 00:14写道：
>
>> On 8/12/25 01:24, px shi wrote:
>> >
>> > 1) What is the current archiving setup on the primary and why is
>> > lagging?
>> >
>> > The archive command uses pgBackRest to archive to S3. Because it is
>> > uploaded to S3, the archiving speed is slow, which has caused lagging.
>> >
>> > 2) Have you looked at archiving off the standby node while it is in
>> > standby per:
>> >
>> > Yes, archiving on the standby node is disabled. Is it recommended to
>> > share the WAL archive between the primary and standby nodes to avoid
>> > interruptions in archiving?
>>
>> Given that you are using a less then capable storage solution(S3) why do
>> you think pushing the WAL from the standby to S3 would perform any
>> better then what is happening with the primary WAL?
>>
>> The solution is to use a more capable storage platform.
>>
>> >
>> > Adrian Klaver <[email protected]
>> > <mailto:[email protected]>> 于2025年8月8日周五 23:23写道：
>> >
>>
>> --
>> Adrian Klaver
>> [email protected]
>>
>
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
view thread (12+ messages) latest in thread
reply
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: [email protected]
Cc: [email protected], [email protected]
Subject: Re: Questions about the continuity of WAL archiving
In-Reply-To: <CANzqJaD-pOt=0CBFXUPEXMtD8AMi_y76z4=Rak405+Rhui4hKQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox