[
https://issues.apache.org/jira/browse/KUDU-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17448795#comment-17448795
]
Alexey Serbin commented on KUDU-2943:
-------------------------------------
[~yejiabao_h]: I'd suggest to start with a different question -- why to
increase term for the leader which steps down? You could get better
understanding of that reading commit description for
https://github.com/apache/kudu/commit/f6777db35dfb3880ea188990809102d167c6d557
(or the review item you referred to: https://gerrit.cloudera.org/#/c/11122/)
Essentially, that's just a workaround to avoid triggering the logic in the
catalog manager's code when leader UUID is left empty in the report from a
tablet server.
The incremented Raft term should not be persisted on disk since that's not
something that Raft consensus agreed upon and consistent in the majority of
replicas. IIUC, doing so could disrupt the Raft consensus bootstrapping later
on in some corner cases (like all the replicas go down right after the
information on non-agreed term is persisted in the metadata of the step-down
leader and another leader is elected by the majority of rest of the replicas).
With that, I'm not sure the solution you proposed is viable.
> TsTabletManagerITest.TestTableStats flaky due to WAL/cmeta term disagreement
> ----------------------------------------------------------------------------
>
> Key: KUDU-2943
> URL: https://issues.apache.org/jira/browse/KUDU-2943
> Project: Kudu
> Issue Type: Bug
> Components: consensus, test
> Affects Versions: 1.11.0
> Reporter: Adar Dembo
> Priority: Critical
> Attachments: ts_tablet_manager-itest.txt
>
>
> This new test failed in a strange (and worrying) way:
> {noformat}
> /home/jenkins-slave/workspace/kudu-master/1/src/kudu/integration-tests/ts_tablet_manager-itest.cc:753:
> Failure
> Failed
> Bad status: Corruption: Unable to start RaftConsensus: The last op in the WAL
> with id 3.4 has a term (3) that is greater than the latest recorded term,
> which is 2
> {noformat}
> From a brief dig through the code, looks like this means the current term as
> per the on-disk cmeta file is older than the term in the latest WAL op.
> I can believe that this is somehow due to InternalMiniCluster exercising
> clean shutdown paths that aren't well tested or robust, but it'd be nice to
> determine that with certainty.
> I've attached the full test log.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
