[
https://issues.apache.org/jira/browse/IGNITE-19763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-19763:
---------------------------------
Epic Link: IGNITE-20612 (was: IGNITE-19743)
> 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)
