[
https://issues.apache.org/jira/browse/IGNITE-10078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805178#comment-16805178
]
Alexey Goncharuk commented on IGNITE-10078:
-------------------------------------------
[~ascherbakov], can you elaborate on the {{dataStore().reserve(cntr)}} logic?
I think we can improve code organization, the following line, for example,
bothers me:
{code}
msg.add(p, mvcc ? part.getAndIncrementUpdateCounter(cntr) :
part.dataStore().reserve(cntr), cntr);
{code}
We can safely rely on the fact that a transaction cannot transact between MVCC
and non-MVCC caches. Thus, no need to pass a flag to
{{calculatePartitionUpdateCounters}}. Also, it is confusing to obtain partition
counters either from {{GridDhtLocalPartition}} or from {{part.dataStore()}}.
The distinction can be done inside the partition based on MVCC or non-MVCC
cache context.
I think we should unify partition counters acquire logic in transactional code
as much as possible.
> Node failure during concurrent partition updates may cause partition desync
> between primary and backup.
> -------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-10078
> URL: https://issues.apache.org/jira/browse/IGNITE-10078
> Project: Ignite
> Issue Type: Bug
> Reporter: Alexei Scherbakov
> Assignee: Alexei Scherbakov
> Priority: Major
> Fix For: 2.8
>
>
> This is possible if some updates are not written to WAL before node failure.
> They will be not applied by rebalancing due to same partition counters in
> certain scenario:
> 1. Start grid with 3 nodes, 2 backups.
> 2. Preload some data to partition P.
> 3. Start two concurrent transactions writing single key to the same partition
> P, keys are different
> {noformat}
> try(Transaction tx = client.transactions().txStart(PESSIMISTIC,
> REPEATABLE_READ, 0, 1)) {
> client.cache(DEFAULT_CACHE_NAME).put(k, v);
> tx.commit();
> }
> {noformat}
> 4. Order updates on backup in the way such update with max partition counter
> is written to WAL and update with lesser partition counter failed due to
> triggering of FH before it's added to WAL
> 5. Return failed node to grid, observe no rebalancing due to same partition
> counters.
> Possible solution: detect gaps in update counters on recovery and force
> rebalance from a node without gaps if detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
