[jira] [Commented] (IGNITE-23328) Check if current resetPartitions mechanism ready for reuse in the HA mode

["Kirill Gusakov (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-23328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17893800#comment-17893800 ] 

Kirill Gusakov commented on IGNITE-23328:
-----------------------------------------

Actually, after some investigations under the we discovered, that we need only one property from resetPartitions in the scope of concurrent invocations:
 * Protection from reordering issues. So, if we call resets [A,B,C] → [A,B] → [A] they can’t be reordered.

*Results*
 * When the future of DisasterRecoveryManager#resetPartitions is done - we have a guerantee, that the ongoing request is

 ** saved to the local ongoing operation list

 ** saved to metastore

 * On the local side DisasterRecoveryManager produce the metastorage record about pending assignments
*So, on the local side it looks like the example chain can’t be reordered*

 * On the receivers side pending assignments will be handled in the pseudo-syncronous manner. It means the that metastore event future will be done only after the actual reset of raft configuration.
*So, on the remote side (every node which receive assignments update) we have no issues also.*

Some details:
 * Actually, we call resetPartitions not with the actual node list, but with the 

{{  public CompletableFuture<Void> resetPartitions(String zoneName, String tableName, Set<Integer> partitionIds) }}

And then
 * Prepare the ManualGroupUpdateRequest(UUID operationId, int catalogVersion, int zoneId, int tableId, Set<Integer> partitionIds)

 * Which will be handled by metastore listener. During this phase we have the concrete metastore revision, which will be used to receive the actual list of data nodes {*}at the event firing moment{*}.

 * But the same time call to topology list is not covered with the metastore revision, W{*}e need to update this call with revision also{*}

*As a result, it looks like with the some additions we can reuse the resetPartitions approach.*

> Check if current resetPartitions mechanism ready for reuse in the HA mode
> -------------------------------------------------------------------------
>
>                 Key: IGNITE-23328
>                 URL: https://issues.apache.org/jira/browse/IGNITE-23328
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Kirill Gusakov
>            Assignee: Kirill Gusakov
>            Priority: Major
>              Labels: ignite-3
>
> *Motivation*
> We have some plans to implement the rebalance cancel mechanism, when the collocation track will be done IGNITE-22115. But at the same time we have significant difficulties with it already now. So, we need to design the lightweight cancel mechanism already now. 
> *Defition of done*
> - We can cancel rebalance at the any rebalance state. Also, it must work with the lost majority
> *Implementation details*
> - IGNITE-22036 can help, because the PrimaryReplica can be the only actor, which run and cancel rebalances



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