[
https://issues.apache.org/jira/browse/IGNITE-13265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17187327#comment-17187327
]
Vladislav Pyatkov commented on IGNITE-13265:
--------------------------------------------
[~ascherbakov] I described algorithm in a ticket description and fixed a case
which you doubted.
Please look at these changes again.
> Historical iterator for atomic group should transfer few more rows than
> required
> --------------------------------------------------------------------------------
>
> Key: IGNITE-13265
> URL: https://issues.apache.org/jira/browse/IGNITE-13265
> Project: Ignite
> Issue Type: Improvement
> Reporter: Vladislav Pyatkov
> Assignee: Vladislav Pyatkov
> Priority: Major
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> On a historical rebalance some updates move from one node to another wherein
> this update may have various order in nodes. Reordering can happen in smell
> interval, but it cannot avoid at all in current implementation atomic
> protocol.
> This mean we will reduce a probably of loosing update if we make a margin
> from initial counter for the historical iterator on atomic cache.
> The final algorithm of choosing correct WAL pointer for atomic cache with the
> margin is:
> 1) Find a checkpoint which contains a counter, that necessary for history
> rebalance (just like a transactional cache)
> 2) If the checkpoint starts with a counter less than which is necessary with
> margin, we are taking it.
> 3) If we are going out of WAL reservation, we are taking current.
> 4) Otherwise we are looking of a previous checkpoint and taking it if it
> starts from a counter less than next checkpoint (from the point 2).
> 5) Else we are still taking the checkpoint from the point 2.
> Other words (points 3-5) the algorithm tries to check only one previous
> checkpoint and takes it if that has different counter.
> *UPD:*
> After a discussion I found a bug connected with using a WAL which was not
> reserved before for preloading.
> I added an explicitly checking this and an appropriate test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
