[jira] [Assigned] (IGNITE-24538) Describe algorithm in the HA mode which solves force reset rewriting scheduled rebalance problem

["Alexander Lapin (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-24538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Lapin reassigned IGNITE-24538:
----------------------------------------

    Assignee: Mirza Aliev

> Describe algorithm in the HA mode which solves force reset rewriting scheduled rebalance problem 
> -------------------------------------------------------------------------------------------------
>
>                 Key: IGNITE-24538
>                 URL: https://issues.apache.org/jira/browse/IGNITE-24538
>             Project: Ignite
>          Issue Type: Task
>            Reporter: Mirza Aliev
>            Assignee: Mirza Aliev
>            Priority: Major
>              Labels: ignite-3
>
> h3. Motivation
> While we was implementing task with extending test coverage (https://issues.apache.org/jira/browse/IGNITE-24410), we have found a scenario where we lost majority, change filter and after that automatic reset try to reset majority, it turned out that force reset rewrites intent to rebalance partition that was triggered by filter change, and moreover, this intent won't be triggered again. In that case user needs to change filter again, which looks a bit odd.
> Detailed scenario: 
> _Precondition_
>  - Create an HA zone with a filter that allows nodes A, B and C.
>  - Make sure {{partitionDistributionResetTimeout}} is high enough not to trigger before the following actions happen
>  - Stop nodes B and C
>  - Change zone filter to allow nodes D, E and F. These new nodes should be up and running
>  - Change {{partitionDistributionResetTimeout}} to a smaller value or 0 to trigger automatic reset
> _Result_
> The partition remains on node A
> _Expected result_
> The partition is moved to D, E and F as per the filter
> The same problem could happen to scale up/scale down or other rebalance triggers, which are about to be applied, but all of sudden majority is lost and such intents will be lost.
> In this task we need to come up with algorithm to resolve such issues.
> Expected behaviour is that filter change event, or other events that changed assignments must be some how applied when majority was lost and recovered concurrently after such events. 
> h3. Implementation notes
> Some ideas, that could help:
> when we do 2 phase reset, when we write single node with most up-to-date raft log to pending in froce manner, we also write planned with the rest alive nodes from stable. Instead of writing such planned, we could write planned in accordance with the pending that was before the moment we try to write new force pending.
> In our example, we could write D,E,F to planned instead of empty set.
> h3. Definition of Done
> * We have described algorithm that solves the problem of lost pending rebalances when we write force pending on majority lost   



--
This message was sent by Atlassian Jira
(v8.20.10#820010)