Re: Extending BASE_BACKUP in replication protocol: incremental backup and backup format

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Extending BASE_BACKUP in replication protocol: incremental backup and backup format
Дата
Msg-id 52D62EDC.9040301@nasby.net
обсуждение исходный текст
Ответ на Re: Extending BASE_BACKUP in replication protocol: incremental backup and backup format  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: Extending BASE_BACKUP in replication protocol: incremental backup and backup format  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
On 1/14/14, 7:41 AM, Magnus Hagander wrote:
>     Yes, it would be necessary to scan the whole database as the LSN to be
>     checked is kept in PageHeaderData :). Perhaps it is not that
>     performant, but my initial thought was that perhaps the amount of data
>     necessary to maintain incremental backups could balance with the
>     amount of WAL necessary to keep and limit the whole amount on disk.
>
>
> It wouldn't be worse performance wise than a full backup. That one also has to read all the blocks after all...
You'redecreasing network traffic and client storage, with the same I/O on the server side. Seems worthwhile.
 

If there's enough demand, it probably wouldn't be that hard to keep a copy of the page LSNs in a fork; you only need to
ensurethat the LSN in the fork must be older than the LSN on disk could possibly be, and you wouldn't have to update
thefork every time.
 

BTW, an incremental backup could possibly be useful as a way to catch a streaming replica up that's fallen way behind.
Thewrite IO would be sequential instead of trying to random-write while processing each WAL record.
 
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net



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

Предыдущее
От: "Erik Rijkers"
Дата:
Сообщение: Re: tests for client programs
Следующее
От: KONDO Mitsumasa
Дата:
Сообщение: drop duplicate buffers in OS