ignite-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Pereslegin (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (IGNITE-10058) resetLostPartitions() leaves an additional copy of a partition in the cluster
Date Wed, 21 Nov 2018 08:43:00 GMT

    [ https://issues.apache.org/jira/browse/IGNITE-10058?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16694381#comment-16694381
] 

Pavel Pereslegin edited comment on IGNITE-10058 at 11/21/18 8:42 AM:
---------------------------------------------------------------------

This small patch evicts duplicate {{LOST}} partitions on non-affinity nodes after node re-joins
the cluster (after step 4).
Affinity assignment is changed in {{CacheAffinitySharedManager#checkRebalanceState}} if it
notices that there is a new affinity-node for {{LOST}} partition.


was (Author: xtern):
This small patch evicts duplicate {{LOST}} partitions on non-affinity nodes after node re-joins
the cluster (after step 4).
Affinity is changed in {{CacheAffinitySharedManager#checkRebalanceState}} if it notices that
there is a new affinity-node for {{LOST}} partition.

> resetLostPartitions() leaves an additional copy of a partition in the cluster
> -----------------------------------------------------------------------------
>
>                 Key: IGNITE-10058
>                 URL: https://issues.apache.org/jira/browse/IGNITE-10058
>             Project: Ignite
>          Issue Type: Bug
>            Reporter: Stanislav Lukyanov
>            Assignee: Pavel Pereslegin
>            Priority: Major
>
> If there are several copies of a LOST partition, resetLostPartitions() will leave all
of them in the cluster as OWNING.
> Scenario:
> 1) Start 4 nodes, a cache with backups=0 and READ_WRITE_SAFE, fill the cache
> 2) Stop one node - some partitions are recreated on the remaining nodes as LOST
> 3) Start one node - the LOST partitions are being rebalanced to the new node from the
existing ones
> 4) Wait for rebalance to complete
> 5) Call resetLostPartitions()
> After that the partitions that were LOST become OWNING on all nodes that had them. Eviction
of these partitions doesn't start.
> Need to correctly evict additional copies of LOST partitions either after rebalance on
step 4 or after resetLostPartitions() call on step 5.
> Current resetLostPartitions() implementation does call checkEvictions(), but the ready
affinity assignment contains several nodes per partition for some reason.



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

Mime
View raw message