Re: Questions about the continuity of WAL archiving - Mailing list pgsql-general

From px shi
Subject Re: Questions about the continuity of WAL archiving
Date
Msg-id CAAccyYL1tE956RWaRrP-2a-Z+TBhsUi3QS+qO_BXjiHnNcFgog@mail.gmail.com
Whole thread Raw
In response to Re: Questions about the continuity of WAL archiving  (Greg Sabino Mullane <htamfids@gmail.com>)
List pgsql-general
I'm still not clear on what the problem here is, other than your archiving 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=always 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> 于2025年8月9日周六 02:25写道:
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 the 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 archiving not keeping up. The best solution to that is:


Yes, you would lost some ability for easy PITR for 80-100, but could still be done by resurrecting your crashed primary, or carefully grabbing from the replica before they get recycled. You can set archive_mode=always on the replicas to help with this.
 
Cheers,
Greg

--
Enterprise Postgres Software Products & Tech Support

pgsql-general by date:

Previous
From: px shi
Date:
Subject: Re: Questions about the continuity of WAL archiving
Next
From: px shi
Date:
Subject: Re: Questions about the continuity of WAL archiving