From: | Ron Johnson <ronljohnsonjr(at)gmail(dot)com> |
---|---|
To: | "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Questions about the continuity of WAL archiving |
Date: | 2025-08-08 18:45:02 |
Message-ID: | CANzqJaBdhehezNtnaC_=08abyozUTo=YwW-Ma1PAzx-mg56Rgg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Aug 8, 2025 at 2:26 PM Greg Sabino Mullane <htamfids(at)gmail(dot)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:
>
>
> 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.
>
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!
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2025-08-08 22:43:13 | Re: When UPDATE a row in a table with BEFORE ROW UPDATE trigger, the XMAX of new tuple is set to current XID |
Previous Message | Greg Sabino Mullane | 2025-08-08 18:25:13 | Re: Questions about the continuity of WAL archiving |