[ https://issues.apache.org/jira/browse/IGNITE-23735 ]
Mirza Aliev deleted comment on IGNITE-23735:
--------------------------------------
was (Author: maliev):
h3. Motivation
In https://issues.apache.org/jira/browse/IGNITE-22904 was implemented logic,
which prevents to leader hijack. More details could be found in the ticket
description, briefly, when node come back after repair, it might still think
it's a member of the voting set, so it might propose itself as a candidate, and
it can win the election if there are enough such nodes. This will result in the
leadership being hijacked by the 'old' majority, which will mess the repaired
Metastorage up.
The same issue could be possible when node that hosted partition come back
after majority reset.
In this ticket we must reuse logic with setting fake conf when node receive
data from new raft group (see
{{org.apache.ignite.raft.jraft.core.NodeImpl#refreshLeadershipAbstaining}}) and
logic of externally enforced config index (see
{{org.apache.ignite.internal.raft.server.RaftGroupOptions#externallyEnforcedConfigIndex()}})
h3. Definition of done
* Nodes that join after partition majority reset must not elect a leader from
the old majority that could hijack leadership and cause havoc in the repaired
group.
> resetPartitions improvements: leader hijack protection must be implemented
> --------------------------------------------------------------------------
>
> Key: IGNITE-23735
> URL: https://issues.apache.org/jira/browse/IGNITE-23735
> Project: Ignite
> Issue Type: Improvement
> Reporter: Mirza Aliev
> Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> In https://issues.apache.org/jira/browse/IGNITE-22904 was implemented logic,
> which prevents to leader hijack. More details could be found in the ticket
> description, briefly, when node come back after repair, it might still think
> it's a member of the voting set, so it might propose itself as a candidate,
> and it can win the election if there are enough such nodes. This will result
> in the leadership being hijacked by the 'old' majority, which will mess the
> repaired Metastorage up.
> The same issue could be possible when node that hosted partition come back
> after majority reset.
> In this ticket we must reuse logic with setting fake conf when node receive
> data from new raft group (see
> {{org.apache.ignite.raft.jraft.core.NodeImpl#refreshLeadershipAbstaining}})
> and logic of externally enforced config index (see
> {{org.apache.ignite.internal.raft.server.RaftGroupOptions#externallyEnforcedConfigIndex()}})
> h3. Definition of done
> * Nodes that join after partition majority reset must not elect a leader from
> the old majority that could hijack leadership and cause havoc in the repaired
> group.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
