[jira] [Updated] (IGNITE-7384) MVCC TX: Support historical rebalance

["Igor Seliverstov (JIRA)" <ji...@apache.org>]

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

Igor Seliverstov updated IGNITE-7384:
-------------------------------------
    Description: 
Currently MVCC doesn't support historical (delta) rebalance.

The main difficulty is that MVCC writes changes on tx active phase while partition update version, aka update counter, is being applied on tx finish. This means we cannot start iteration over WAL right from the pointer where the update counter updated, but should include updates, which the transaction that updated the counter did.

Currently proposed approach:

Maintain a list of active TXs with update counter (UC) which was actual at the time before TX did its first update (on per partition basis)
on each checkpoint save two counters - update counter (UC) and back counter (BC) which is earliest UC mapped to a tx from active list at checkpoint time.
during local restore move UC and BC forward as far as possible. 
send BC instead of update counter in demand message.
start iteration from a first checkpoint having UC less or equal received BC

See linked dev list thread for details

  was:
In case a node returns to topology it requests a delta instead of full partition, WAL-based iterator is used there ({{o.a.i.i.processors.cache.persistence.GridCacheOffheapManager#rebalanceIterator}})

WAL-based iterator doesn't contain MVCC versions which causes issues.


> MVCC TX: Support historical rebalance
> -------------------------------------
>
>                 Key: IGNITE-7384
>                 URL: https://issues.apache.org/jira/browse/IGNITE-7384
>             Project: Ignite
>          Issue Type: Task
>          Components: mvcc
>            Reporter: Igor Seliverstov
>            Priority: Major
>             Fix For: 2.8
>
>
> Currently MVCC doesn't support historical (delta) rebalance.
> The main difficulty is that MVCC writes changes on tx active phase while partition update version, aka update counter, is being applied on tx finish. This means we cannot start iteration over WAL right from the pointer where the update counter updated, but should include updates, which the transaction that updated the counter did.
> Currently proposed approach:
> Maintain a list of active TXs with update counter (UC) which was actual at the time before TX did its first update (on per partition basis)
> on each checkpoint save two counters - update counter (UC) and back counter (BC) which is earliest UC mapped to a tx from active list at checkpoint time.
> during local restore move UC and BC forward as far as possible. 
> send BC instead of update counter in demand message.
> start iteration from a first checkpoint having UC less or equal received BC
> See linked dev list thread for details



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)