[jira] [Updated] (IGNITE-15493) Need to clarify changePeers behavior to support the case with only one replica which should be moved during rebalance

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

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

Alexander Lapin updated IGNITE-15493:
-------------------------------------
    Description: 
Need to clarify the behavior of changePeers (IGNITE-15288) method in case of a raft group contains only one raw node and it should be moved to a new Ignite node. 
h4. Upd 1

Following open points should be clarified:
 * Is it possible to change peers for the case when the old and new sets of raft nodes do not intersect? As Kirill Gusakov mentioned seems that it’s possible, see ITJRaftCounterServerTest#testRebalance

 * When changePeers() returns to the client? We assume that it returns after appliance on both old and new raft group typologies. It’s also expected that changePeers is a raft command that’s as any other raft commands have an index and will be applied after commands with lower index, which actually means that data rebalance to the majority of nodes within new topology will be finished before applying change peers. Let’s check whether it’s true:

 ** Let’s check whether dataRebalance is a raft command that works just as any other raft commands and do not expect index gaps.

 ** Let’s check that snapshot works the same way as log-rebalance in the context of index moving.

 ** If all true, how it’s possible to have changePeers invoke that will last for “new majority time“ that may take hours or event days?

  was:Need to clarify the behavior of changePeers (IGNITE-15288) method in case of a raft group contains only one raw node and it should be moved to a new Ignite node. 


> Need to clarify changePeers behavior to support the case with only one replica which should be moved during rebalance
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: IGNITE-15493
>                 URL: https://issues.apache.org/jira/browse/IGNITE-15493
>             Project: Ignite
>          Issue Type: Sub-task
>            Reporter: Vyacheslav Koptilin
>            Priority: Major
>              Labels: ignite-3
>
> Need to clarify the behavior of changePeers (IGNITE-15288) method in case of a raft group contains only one raw node and it should be moved to a new Ignite node. 
> h4. Upd 1
> Following open points should be clarified:
>  * Is it possible to change peers for the case when the old and new sets of raft nodes do not intersect? As Kirill Gusakov mentioned seems that it’s possible, see ITJRaftCounterServerTest#testRebalance
>  * When changePeers() returns to the client? We assume that it returns after appliance on both old and new raft group typologies. It’s also expected that changePeers is a raft command that’s as any other raft commands have an index and will be applied after commands with lower index, which actually means that data rebalance to the majority of nodes within new topology will be finished before applying change peers. Let’s check whether it’s true:
>  ** Let’s check whether dataRebalance is a raft command that works just as any other raft commands and do not expect index gaps.
>  ** Let’s check that snapshot works the same way as log-rebalance in the context of index moving.
>  ** If all true, how it’s possible to have changePeers invoke that will last for “new majority time“ that may take hours or event days?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)