[
https://issues.apache.org/jira/browse/IGNITE-15514?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490965#comment-17490965
]
Kirill Gusakov commented on IGNITE-15514:
-----------------------------------------
According to the current rebalance design
[https://github.com/apache/ignite-3/blob/main/modules/table/tech-notes/rebalance.md]
we will update the raft clients after the changes in stable assignments. But
we case from the current issues is not covered by this algorithm.
Maybe we need to force client update on special types of received errors from
the current client or something like that.
> Add guaranties of using appropriate affinity assignments from lagged node
> after reassignment.
> ---------------------------------------------------------------------------------------------
>
> Key: IGNITE-15514
> URL: https://issues.apache.org/jira/browse/IGNITE-15514
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Assignee: Kirill Gusakov
> Priority: Major
> Labels: ignite-3
>
> Let's consider following example:
> # tbl1 true assignment(ms hosted) is A,B,C. Raft is up and running on A,B,C.
> On node A it's known that tbl1 assignment is A,B,C.
> # Assignment recalculation was triggered that moved true assignment from
> A,B,C to D,E,F(ms hosted). Raft is up and running on D,E,F. Node A still
> assumes that tbl1 assignment is A,B,C cause it didn't get update from meta
> storage about reassignment yet.
> # User tries to put or get data to/from tbl1 from node A. Internally he
> tries to retrieve raft leader, assuming that it's either on A, B or C. Given
> assumption is wrong, so that he will fail with something similar to
> TimeoutException.
> Seems that we need a solution that will guarantee that appropriate true
> assignment is used.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
