Using the AWS tutorial will get you a backup filter using this implementation: ClusterNodeAttributeAffinityBackupFilter
There is logic to prevent a cascade of backup data onto survivor nodes in case of multiple concurrent failures if you read the documentation. https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/cache/affinity/rendezvous/ClusterNodeAttributeAffinityBackupFilter.html "This implementation will discard backups rather than place multiple on the same set of nodes. This avoids trying to cram more data onto remaining nodes when some have failed." If you don't have enough nodes to support backups, this implementation will sacrifice backups to keep the cluster operating. It isn't clear if this question is a hypothetical understanding of features and functionality, or whether you have a design problem you need to solve. On Mon, Oct 31, 2022 at 8:01 AM Surinder Mehra <[email protected]> wrote: > Hi, > As per link attached, to ensure primary and backup partitions are not > stored on same node, We used AWS AZ as backup filter and now I can see if I > start two ignite nodes on the same machine, primary partitions are evenly > distributed but backups are always zero which is expected. > > > https://www.gridgain.com/docs/latest/installation-guide/aws/multiple-availability-zone-aws > > My question is what would happen if AZ-1 has 2 machines and AZ-2 has 1 > machine and ignite cluster has only 3 nodes, each machine having one ignite > node. > > Node1[AZ1] - keys 1-100 > Node2[AZ1] - keys 101-200 > Node3[AZ2] - keys 201 -300 > > In the above scenario, if the backup count is 2, how would back up > partitions be distributed. > > 1. Would it mean node3 will have 2 backup copies of primary partitions of > node 1 and 2 ? > 2. If we have a 4 node cluster with 2 nodes in each AZ, would backup > copies also be placed on different nodes(In other words, does the backup > filter also apply to how backup copies are placed on nodes) ? > > >
