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

Denis Magda closed IGNITE-2655.
-------------------------------

> AffinityFunction: primary and backup copies in different locations
> ------------------------------------------------------------------
>
>                 Key: IGNITE-2655
>                 URL: https://issues.apache.org/jira/browse/IGNITE-2655
>             Project: Ignite
>          Issue Type: Bug
>            Reporter: Denis Magda
>            Assignee: Vladislav Pyatkov
>            Priority: Critical
>              Labels: important
>             Fix For: 1.7
>
>
> There is a use case when primary and backup copies have to be located in 
> different racks, building, cities, etc.
> A simple scenario is the following. When nodes are started they will have 
> either "rack1" or "rack2" value in their attributes list and we will enforce 
> that the backups won't be selected among the nodes with the same attribute.
> It should be possible to filter out backups using IP addresses as well.
> Presently rendezvous and fair affinity function has {{backupFilter}} that 
> will work perfectly for the scenario above but only for cases when number of 
> backups for a cache is equal to 1.
> In case when the number of backups is bigger than one {{backupFilter}} will 
> only guarantee that the primary is located in different location but will NOT 
> guarantee that all the backups are spread out across different locations as 
> well.
> So we need to provide an API that will allow to spread the primary and ALL 
> backups copies across different locations.
> The proposal is to introduce {{AffinityBackupFilter}} with the following 
> method
> {{AffinityBackupFilter.isAssignable(Node n, List<Node> assigned)}}
> Where n - potential backup to check, assigned - list of current partition 
> holders, 1st is primary
> {{AffinityBackupFilter}} will be set using 
> {{affinity.setAffinityBackupFilter}}.
> {{Affinity.setBackupFilter}} has to be deprecated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to