[
https://issues.apache.org/jira/browse/RATIS-1879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17760507#comment-17760507
]
Xinyu Tan commented on RATIS-1879:
----------------------------------
{quote}Should it be "once the appendLog function is completed"?
{quote}
Yes, your description is more accurate!
{quote}
Sorry that I might have chosen a wrong word. I should have said "unflushed" or
"unpersisted" instead of "uncommitted". I mean writing a log entry is a
process,. It can fail in the middle no matter how we write it. As long as we
don't increase the index until the write is completed. We are fine.
{quote}
OK, Cann't agree more. It's a process.
{quote} Agree. We should have some way to fix a corrupted log.
{quote}
So, when such situations arise, in order to expedite the cluster's startup,
should we filter out these issues during the recovery process of the raftlog
(similar to your proposed changes in the pull request)? Or should we create a
new repair tool? Do you have any preference? Perhaps we can work together to
initially strive towards a certain direction~:)
> Handle RaftLog corruption when unsafe flush is enabled.
> -------------------------------------------------------
>
> Key: RATIS-1879
> URL: https://issues.apache.org/jira/browse/RATIS-1879
> Project: Ratis
> Issue Type: Bug
> Components: server
> Affects Versions: 3.0.0, 2.5.1
> Reporter: Song Ziyang
> Assignee: Tsz-wo Sze
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> During normal operations of the RaftServer, its containing virtual machine
> (VM) was unexpectedly shut down and subsequently restarted. Following the VM
> reboot, *our attempts to restart the RaftServer led to encountering the
> subsequent exception, indicating corruption in the Raft* {*}Log{*}{*}.{*}
> *The details of this exception please refer to
> [https://apache-iotdb.feishu.cn/docx/Zmyudq0FYoDVcsxDwHpcINyznfg]*
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
