On 2020/04/22 9:13, Kyotaro Horiguchi wrote:
At Tue, 21 Apr 2020 22:08:56 +0900, Fujii Masao <masao.fu...@oss.nttdata.com>
wrote in
On 2020/04/21 17:15, Kyotaro Horiguchi wrote:
At Mon, 20 Apr 2020 15:26:16 +0900, Fujii Masao
<masao.fu...@oss.nttdata.com> wrote in
Patch attached. I will add this into the first CF for v14.
- if (!fast_promoted)
+ if (!promoted)
RequestCheckpoint(CHECKPOINT_END_OF_RECOVERY |
CHECKPOINT_IMMEDIATE |
CHECKPOINT_WAIT);
If we don't find the checkpoint record just before, we don't insert
End-Of-Recovery record then run an immediate chekpoint. I think if we
nuke the non-fast promotion, shouldn't we insert the EOR record even
in that case?
I'm not sure if that's safe. What if the server crashes before the
checkpoint
completes in that case? Since the last checkpoint record is not
available,
the subsequent crash recovery will fail. This would lead to that the
server
will never start up. Right? Currently ISTM that
Yes, that's right.
end-of-recovery-checkpoint
is executed to avoid such trouble in that case.
I meant that we always have EOR at the end of recovery. So in the
missing latest checkpoint (and crash recovery) case, we insert EOR
after the immediate checkpoint. That also means we no longer set
CHECKPOINT_END_OF_RECOVERY to the checkpoint, too.
Could you tell me what the benefit by this change is? Even with this change,
the server still needs to wait for the checkpoint to complete before
becoming the master and starting the service, unlike fast promotion. No?
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
