You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Yaroslav Molochkov (Jira)" <ji...@apache.org> on 2020/11/03 15:14:00 UTC

[jira] [Updated] (IGNITE-13265) Historical iterator for atomic group should transfer few more rows than required

     [ https://issues.apache.org/jira/browse/IGNITE-13265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yaroslav Molochkov updated IGNITE-13265:
----------------------------------------
    Fix Version/s: 2.9.1

> 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
>              Labels: 2.9.1-rc
>             Fix For: 2.10, 2.9.1
>
>          Time Spent: 3.5h
>  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)