You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rocketmq.apache.org by GitBox <gi...@apache.org> on 2022/10/08 02:12:41 UTC

[GitHub] [rocketmq] lizhimins commented on issue #5209: Should truncate the commitLog base on confirmOffset?

lizhimins commented on issue #5209:
URL: https://github.com/apache/rocketmq/issues/5209#issuecomment-1272197831

   Messages between these two offset may confirmed by master, so slave should compute confirmOffset to maxOffset first.
   
   当一条日志被传输到 Follower,Follower 确认收到这条消息,主再把这条日志应用到自己的状态机时,通知客户端和通知所有的 follower 去 commit 这条日志这两件事是并行的,假如 leader 先回复 client 处理成功,此时 leader 宕机,由于其他 follower 的确认位点 confirm offset 一般会略低于 leader,中间这段未决日志还没应用到 follower 的状态机上,这时就出现了状态机不一致的情况,即已经写入 leader 的数据丢失了。所以当备切换为主的时候,直接截断,意味着客户端已经发送到服务端的消息丢失了,正确的水位应该被提升 max offset。但是备还没有收到 confirm 的 event,这个行为相当于要提交了未决消息。事实上新 leader 会遵守 "Leader Completeness" 的约定,切换时任何副本都不会删除也不会更改旧 leader 未决的 entry。新 leader 在新的 term 下,会直接应用一个较大的版本�
 ��未决的 entry 一起提交,这里副本组主备节点的行为共同保证了复制状态机的安全性。


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: dev-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org