Re: Patch for fail-back without fresh backup

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Patch for fail-back without fresh backup
Дата
Msg-id 52690F77.4080903@vmware.com
обсуждение исходный текст
Ответ на Re: Patch for fail-back without fresh backup  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Ответы Re: Patch for fail-back without fresh backup  (Pavan Deolasee <pavan.deolasee@gmail.com>)
Список pgsql-hackers
On 24.10.2013 14:15, Pavan Deolasee wrote:
> On Thu, Oct 24, 2013 at 4:22 PM, Heikki Linnakangas<hlinnakangas@vmware.com
>> wrote:
>
>> To fix that, pg_rewind could always start the rewinding process from the
>> last checkpoint before the point that the histories diverge, instead of the
>> exact point of divergence.
>
> Is that something required even if someone plans to use pg_rewind for a
> cluster with checksums enabled ? I mean since only first update after
> checkpoint is WAL logged, pg_rewind will break if another update happens
> after standby forks.

Yes. It's broken as it is, even when checksums are enabled - good catch. 
I'll go change it to read all the WAL in the target starting from the 
last checkpoint before the point of divergence.

> Or would the recovery logic apply first WAL without
> looking at the page lsn ? (Sorry, may be I should read the code instead of
> asking you)

WAL recovery does apply all the full-page images without looking at the 
page LSN, but that doesn't help in this case. pg_rewind copies over the 
blocks from the source server (= promoted standby) that were changed in 
the target server (= old master), after the standby's history diverged 
from it. In other words, it reverts the blocks that were changed in the 
old master, by copying them over from the promoted standby. After that, 
WAL recovery is performed, using the WAL from the promoted standby, to 
apply all the changes from the promoted standby that were not present in 
the old master. But it never replays any WAL from the old master. It 
reads it through, to construct the list of blocks that were modified, 
but it doesn't apply them.

> If we do what you are suggesting, it seems like a single line patch to me.
> In XLogSaveBufferForHint(), we probably need to look at this additional GUC
> to decide whether or not to backup the block.

Yeah, it's trivial to add such a guc. Will just have to figure out what 
we want the user interface to be like; should it be a separate guc, or 
somehow cram it into wal_level?

- Heikki



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

Предыдущее
От: Pavan Deolasee
Дата:
Сообщение: Re: Patch for fail-back without fresh backup
Следующее
От: Pavan Deolasee
Дата:
Сообщение: Re: Patch for fail-back without fresh backup