Re: Incremental backup from a streaming replication standby fails

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Incremental backup from a streaming replication standby fails
Дата
Msg-id CA+TgmoYT3VzgtK8P-7MMNWCP0PJVHFdm2Tw0cPi8e0f2+TmoFQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Incremental backup from a streaming replication standby fails  (Laurenz Albe <laurenz.albe@cybertec.at>)
Список pgsql-hackers
On Mon, Jul 22, 2024 at 1:05 PM Laurenz Albe <laurenz.albe@cybertec.at> wrote:
> Before I write a v2, a small question for clarification:
> I believe I remember that during my experiments, I ran CHECKPOINT
> on the standby server between the first backup and the incremental
> backup, and that was not enough to make it work.  I had to run
> a CHECKPOINT on the primary server.
>
> Does CHECKPOINT on the standby not trigger a restartpoint, or do
> I simply misremember?

It's only possible for the standby to create a restartpoint at a
write-ahead log position where the master created a checkpoint. With
typical configuration, every or nearly every checkpoint on the primary
will trigger a restartpoint on the standby, but for example if you set
max_wal_size bigger and checkpoint_timeout longer on the standby than
on the primary, then you might end up with only some of those
checkpoints ending up becoming restartpoints and others not.

Looking at the code in CreateRestartPoint(), it looks like what
happens if you run CHECKPOINT is that it tries to turn the
most-recently replayed checkpoint into a restartpoint if that wasn't
done already; otherwise it just returns without doing anything. See
the comment that begins with "If the last checkpoint record we've
replayed is already our last".

--
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin
Следующее
От: Ahmed Yarub Hani Al Nuaimi
Дата:
Сообщение: Re: Lock-free compaction. Why not?