Re: Incremental backup from a streaming replication standby fails
От | Robert Haas |
---|---|
Тема | Re: Incremental backup from a streaming replication standby fails |
Дата | |
Msg-id | CA+TgmobigpSed3tMqRkA16-wFCHgf4kSMrDmpiSVmKmz9YhQNQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Incremental backup from a streaming replication standby fails (Laurenz Albe <laurenz.albe@cybertec.at>) |
Ответы |
Re: Incremental backup from a streaming replication standby fails
|
Список | pgsql-hackers |
On Wed, Jul 24, 2024 at 6:46 AM Laurenz Albe <laurenz.albe@cybertec.at> wrote: > An incremental backup is only possible if replay would begin from a later > checkpoint than the checkpoint that started the previous backup upon which > it depends. My concern here is that the previous backup might have been taken on a standby, and therefore it did not start with a checkpoint. For a standby backup, replay will begin from a checkpoint record, but that record may be quite a bit earlier in the WAL. For instance, imagine checkpoint_timeout is set to 30 minutes on the standby. When the backup is taken, the most recent restartpoint could be up to 30 minutes ago -- and it is the checkpoint record for that restartpoint from which replay will begin. I think that in my phrasing, it's always about the checkpoint from which replay would begin (which is always well-defined) not the checkpoint that started the backup (which is only logical on the primary). > If you take the incremental backup on the primary, this > condition is always satisfied, because each backup triggers a new > checkpoint. On a standby, replay begins from the most recent restartpoint. > Therefore, an incremental backup of a standby server can fail if there has > been very little activity since the previous backup, since no new > restartpoint might have been created. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: