Re: Questions about the continuity of WAL archiving
| От | Ron Johnson |
|---|---|
| Тема | Re: Questions about the continuity of WAL archiving |
| Дата | |
| Msg-id | CANzqJaBdhehezNtnaC_=08abyozUTo=YwW-Ma1PAzx-mg56Rgg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Questions about the continuity of WAL archiving (Greg Sabino Mullane <htamfids@gmail.com>) |
| Список | pgsql-general |
On Fri, Aug 8, 2025 at 2:26 PM Greg Sabino Mullane <htamfids@gmail.com> wrote:
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.
Bog-standard PgBackRest retains all WAL files required for a full backup set and its associated differential/incremental backups, no? I've certainly done more than one --type=time --target="${RestoreUntil}" restore without giving a second thought to timelines or whether the WAL exists.
Maybe I've just ignored the problem, since it (seemingly) does everything for PITR backups.
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
В списке pgsql-general по дате отправления: