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?
On 8/7/25 22:50, px shi wrote: > Thank you for your reply. > The archived files can be used for PITR (Point-In-Time Recovery), > allowing recovery to any point between WAL 80 and 100 on timeline 1. > Additionally, if there's a backup taken during timeline 1 and a > switchover to a new primary has occurred without taking a new full > backup yet, these WAL logs can still be used to recover to any point on > timeline 2.
Alright I see.
Two things:
1) What is the current archiving setup on the primary and why is lagging?
2) Have you looked at archiving off the standby node while it is in standby per:
> > Regards, > Pixian Shi > > Adrian Klaver <adrian.klaver@aklaver.com > <mailto:adrian.klaver@aklaver.com>> 于2025年8月8日周五 12:25写道： > > On 8/7/25 20:20, px shi wrote: > > Hi, > > 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. > > What are you planning to do with the archived files? > > Also is not the case that once the primary crashes you are in a split > brain case and can't really trust it's timeline anymore? > > > > Is there a good solution to prevent this situation? > > > > Regards, > > Pixian Shi > > > -- > Adrian Klaver > adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com> >
