Re: pg_rewind, a tool for resynchronizing an old master after failover
От | Heikki Linnakangas |
---|---|
Тема | Re: pg_rewind, a tool for resynchronizing an old master after failover |
Дата | |
Msg-id | 519E5493.5060800@vmware.com обсуждение исходный текст |
Ответ на | Re: pg_rewind, a tool for resynchronizing an old master after failover (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: pg_rewind, a tool for resynchronizing an old master
after failover
|
Список | pgsql-hackers |
On 23.05.2013 07:55, Robert Haas wrote: > On Thu, May 23, 2013 at 7:10 AM, Heikki Linnakangas > <hlinnakangas@vmware.com> wrote: >> 1. Scan the WAL log of the old cluster, starting from the point where >> the new cluster's timeline history forked off from the old cluster. For each >> WAL record, make a note of the data blocks that are touched. This yields a >> list of all the data blocks that were changed in the old cluster, after the >> new cluster forked off. > > Suppose that a transaction is open and has written tuples at the point > where WAL forks. After WAL forks, the transaction commits. Then, it > hints some of the tuples that it wrote. There is no record in WAL > that those blocks are changed, but failing to revert them leads to > data corruption. Bummer, you're right. Hmm, if you have checksums enabled, however, we'll WAL log a full-page every time a page is dirtied for setting a hint bit, which fixes the problem. So, there's a caveat with pg_rewind; you must have checksums enabled. - Heikki
В списке pgsql-hackers по дате отправления: