You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Mirza Aliev (Jira)" <ji...@apache.org> on 2023/10/10 10:28:00 UTC
[jira] [Updated] (IGNITE-19763) Changing empty stable assignments to not empty pending assignments.
[ https://issues.apache.org/jira/browse/IGNITE-19763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mirza Aliev updated IGNITE-19763:
---------------------------------
Description:
h3. *Motivation*
After https://issues.apache.org/jira/browse/IGNITE-19466 will be implemented It will be possible to create a table without data nodes in the distribution zone. Then we will face another issue.
Current flow of changing pending assignments:
# When the zone is updated and has a data nodes then the rebalance will start on new data nodes.
# The method handleChangePendingAssignmentEvent receives an empty stableAssignments and not empty pendingAssignments.
# handleChangePendingAssignmentEvent invokes startRaftGroupNode to start raft group node with stable assignment and start Replica, PartitionReplicaListener.
# After that starts change peers on with pendingAssignments.
It doesn't work properly because if previous stableAssignments is empty then it is not possible to start raft group. And if raft group is not started then it is not possible to change peers. So if stableAssignments is empty then need to skip starting raft group with this assignments and start new raft group with pendingAssignments.
h3. *Definition of Done*
Table without data nodes in the zone must process operations after data nodes are appeared.
*UPD*
It looks like for the described case we should use the following flow:
* On the pending assignments update detect that the stable assignments is empty
* Go to the code track, which handle table creation flow org.apache.ignite.internal.table.distributed.TableManager#createTablePartitionsLocally
* Call changePeersAsync to pendingAssignments. Because the current raft group already has the same configuration, it will just run the onNewPeersConfigurationApplied as usual and move the pending assignments to stable
Caveats:
* changePeersAsync can be called before the all nodes started. But we have the same race in usual rebalance procedure already.
* current onNewPeersConfigurationApplied can be not ready for the processing of empty stable assignments, need to check and fix the logic if needed
was:
h3. *Motivation*
After https://issues.apache.org/jira/browse/IGNITE-19466 will be implemented It will be possible to create a table without data nodes in the distribution zone. Then we will face another issue.
Current flow of changing pending assignments:
# When the zone is updated and has a data nodes then the rebalance will start on new data nodes.
# The method handleChangePendingAssignmentEvent receives an empty stableAssignments and not empty pendingAssignments.
# handleChangePendingAssignmentEvent invokes startRaftGroupNode to start raft group node with stable assignment and start Replica, PartitionReplicaListener.
# After that starts change peers on with pendingAssignments.
It doesn't work properly because if previous stableAssignments is empty then it is not possible to start raft group. And if raft group is not started then it is not possible to change peers. So if stableAssignments is empty then need to skip starting raft group with this assignments and start new raft group with pendingAssignments.
h3. *Definition of Done*
Table without data nodes in the zone must process operations after data nodes are appeared.
> Changing empty stable assignments to not empty pending assignments.
> -------------------------------------------------------------------
>
> Key: IGNITE-19763
> URL: https://issues.apache.org/jira/browse/IGNITE-19763
> Project: Ignite
> Issue Type: Bug
> Reporter: Sergey Uttsel
> Priority: Major
> Labels: ignite-3, tech-debt
>
> h3. *Motivation*
> After https://issues.apache.org/jira/browse/IGNITE-19466 will be implemented It will be possible to create a table without data nodes in the distribution zone. Then we will face another issue.
> Current flow of changing pending assignments:
> # When the zone is updated and has a data nodes then the rebalance will start on new data nodes.
> # The method handleChangePendingAssignmentEvent receives an empty stableAssignments and not empty pendingAssignments.
> # handleChangePendingAssignmentEvent invokes startRaftGroupNode to start raft group node with stable assignment and start Replica, PartitionReplicaListener.
> # After that starts change peers on with pendingAssignments.
> It doesn't work properly because if previous stableAssignments is empty then it is not possible to start raft group. And if raft group is not started then it is not possible to change peers. So if stableAssignments is empty then need to skip starting raft group with this assignments and start new raft group with pendingAssignments.
> h3. *Definition of Done*
> Table without data nodes in the zone must process operations after data nodes are appeared.
> *UPD*
> It looks like for the described case we should use the following flow:
> * On the pending assignments update detect that the stable assignments is empty
> * Go to the code track, which handle table creation flow org.apache.ignite.internal.table.distributed.TableManager#createTablePartitionsLocally
> * Call changePeersAsync to pendingAssignments. Because the current raft group already has the same configuration, it will just run the onNewPeersConfigurationApplied as usual and move the pending assignments to stable
> Caveats:
> * changePeersAsync can be called before the all nodes started. But we have the same race in usual rebalance procedure already.
> * current onNewPeersConfigurationApplied can be not ready for the processing of empty stable assignments, need to check and fix the logic if needed
--
This message was sent by Atlassian Jira
(v8.20.10#820010)