Should truncate the commitLog base on confirmOffset?

Hi Community, i have a silly question, when a slave broker will changing to master and the slave’s confirmOffset get from old master. It will recalculate the confirmOffset when AutoSwitchHAService#changeToMaster, buf if the slave maxOffset > confirmOffset(this broker replicates relatively fast and the confirmOffset is the one that takes the smallest value of all syncStateSets ), In this case, will it cause the inconsistent messages? should we truncate the commitLog between confirmOffset to maxOffset?

Hope all your helps.

[lizhimins]

@lizhimins @RongtongJin Controller模式下应该不太涉及到日志状态机，我提出的疑问是：当前的代码实现，分发领先(dispatchBehind)是用confirmOffset减reputFromOffset，在切换时如果不先把confirmOffset重置到maxOffset，比如reputFromOffset=confirmOffset < maxOffset时，那truncateInvalidMsg可能就有问题了，我的理解是在truncateInvalidMsg前后都应该计算一下confirmOffset。

是的，这个和我的理解一致

• truncate 前 fix confirmOffset = maxOffset 是为了 apply unconfirmed log，这样才能不丢已提交的消息
• truncate 后 fix confirmOffset = last consist point 是为了让主备对齐

[RongtongJin]

Hi @lanlanbaby, it will not truncate the slave’s commitLog between confirmOffset to maxOffset before the slave changing to master. First, the transfer of confirmOffset is delayed, if the commitLog between confirmOffset to maxOffset is truncated, messages may be lost. In addition, we only guarantee that messages will not be lost. Messages between confirmOffset to maxOffset are uncertain (no ack to clients), so it doesn’t matter if these messages exist.