> > 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 <htamf...@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: > > > https://pgbackrest.org/1/configuration.html#section-archive/option-archive-async > > 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 > > -- > Crunchy Data - https://www.crunchydata.com > Enterprise Postgres Software Products & Tech Support > >
