You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Maxim Muzafarov (Jira)" <ji...@apache.org> on 2019/10/10 11:27:00 UTC

[jira] [Updated] (IGNITE-10058) resetLostPartitions() leaves an additional copy of a partition in the cluster

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

Maxim Muzafarov updated IGNITE-10058:
-------------------------------------
    Fix Version/s:     (was: 2.8)

> 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
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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
(v8.3.4#803005)