[
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)
