Re: Skip checkpoint on promoting from streaming replication
От | Heikki Linnakangas |
---|---|
Тема | Re: Skip checkpoint on promoting from streaming replication |
Дата | |
Msg-id | 510166B9.6080705@vmware.com обсуждение исходный текст |
Ответ на | Re: Skip checkpoint on promoting from streaming replication (Simon Riggs <simon@2ndquadrant.com>) |
Ответы |
Re: Skip checkpoint on promoting from streaming replication
(Simon Riggs <simon@2ndQuadrant.com>)
|
Список | pgsql-hackers |
On 24.01.2013 18:24, Simon Riggs wrote: > On 6 January 2013 21:58, Simon Riggs<simon@2ndquadrant.com> wrote: >> I've been torn between the need to remove the checkpoint for speed and >> being worried about the implications of doing so. >> >> We promote in multiple use cases. When we end a PITR, or are >> performing a switchover, it doesn't really matter how long the >> shutdown checkpoint takes, so I'm inclined to leave it there in those >> cases. For failover, we need fast promotion. >> >> So my thinking is to make pg_ctl promote -m fast >> be the way to initiate a fast failover that skips the shutdown checkpoint. >> >> That way all existing applications work the same as before, while new >> users that explicitly choose to do so will gain from the new option. > > Here's a patch to skip checkpoint when we do > > pg_ctl promote -m fast > > We keep the end of recovery checkpoint in all other cases. Hmm, there seems to be no way to do a "fast" promotion with a trigger file. I'm a bit confused why there needs to be special mode for this. Can't we just always do the "fast" promotion? I agree that there's no urgency when you're doing PITR, but shouldn't do any harm either. Or perhaps always do "fast" promotion when starting up from standby mode, and "slow" otherwise. Are we comfortable enough with this to skip the checkpoint after crash recovery? I may be missing something, but it looks like after a "fast" promotion, you don't request a new checkpoint. So it can take quite a while for the next checkpoint to be triggered by checkpoint_timeout/segments. That shouldn't be a problem, but I feel that it'd be prudent to request a new checkpoint immediately (not necessarily an "immediate" checkpoint, though). > The only thing left from Kyotaro's patch is a single line of code - > the call to ReadCheckpointRecord() that checks to see if the WAL > records for the last two restartpoints is on disk, which was an > important line of code. Why's that important, just for paranoia? If the last two restartpoints have disappeared, something's seriously wrong, and you will be in trouble e.g if you crash at that point. Do we need to be extra paranoid when doing a "fast" promotion? > Patch implements a new record type XLOG_END_OF_RECOVERY that behaves > on replay like a shutdown checkpoint record. I put this back in from > my patch because I believe its important that we have a clear place > where the WAL history changes timelineId. WAL format change bump > required. Agreed, such a WAL record is essential. At replay, an end-of-recovery record should be a signal to the hot standby mechanism that there are no transactions running in the master at that point, same as a shutdown checkpoint. - Heikki
В списке pgsql-hackers по дате отправления: