How to use ClusterNodeAttributeAffinityBackupFilter to have atleast one replica in second zone

Hi Team We are planning to run 10 node Ignite clusters in AWS with 5 nodes each into two availability zones. Using Kubernetes topologyspreadconstraints we have made sure that no two Ignite pods are started on the same virtual machine/node/host. I understand with ClusterNodeAttributeAffinityBackup

Re: How to use ClusterNodeAttributeAffinityBackupFilter to have atleast one replica in second zone

Hi Amit, > if the backup count is let's say 2, Ignite won't create a second backup as there are not enough zones Not correct - Ignite will create backups anyway. - A backup is a copy of a partition on another node - With 2 backups every partition will have 3 copies (1 primary, 2 backup), all on d

RE: Failed to execute query because cache partition has been lost

After sending the reply, I was thinking… partitionLossPolicy prevents that someone tries to modify the DB while a partition is lost (this means that a node is not on the cache). So, if I set partitionLossPolicy = IGNORE the DB can be modified when a node is not present. Maybe the solution c

Re: Failed to execute query because cache partition has been lost

> 2 servers and 1 client, and no backups > shut down one node There are no backups => any node shutdown leads to partition loss. If you want to ignore data loss, set partitionLossPolicy = IGNORE [1] [1] https://ignite.apache.org/docs/latest/configuring-caches/partition-loss-policy On Wed, Sep 18

Re: Failed to execute query because cache partition has been lost

I recommend enabling backups in CacheConfiguration to avoid dealing with partition loss at all. Is there any reason not to? On Wed, Sep 18, 2024 at 1:21 PM wrote: > After sending the reply, I was thinking… partitionLossPolicy prevents > that someone tries to modify the DB while a partition is lo

Failed to execute query because cache partition has been lost

Hi. We are using Apache Ignite in our application, and currently, we are testing the behaviour of the system when there are system errors. One of our tests is not working as expected: * we have got an Ignite cluster with 2 servers and 1 client, and no backups * Ignite version 2

RE: Failed to execute query because cache partition has been lost

Ok, thanks, I understand. But in this case, if someone tries to modify the DB while a node is down, does Ignites offers any mechanism to prevent this or should I implement it? From: Pavel Tupitsyn Sent: miércoles, 18 de septiembre de 2024 11:30 To: user@ignite.apache.org Subject: Re: Fai

Re: rejecting communication connection & Failed to process selector key

I suspect your openshift networking is doing something wrong: NAT is particularly suspicious. Share your discovery configuration and openshift network layout. On Mon, Sep 16, 2024 at 4:38 AM MJ <6733...@qq.com> wrote: > Donot think so. As below the remote ip 10.254.13.83 >

Re: Failed to execute query because cache partition has been lost

If you want to do maintenance, and you want to block access during maintenance, inactivate the cluster, then do the maintenance, then activate the cluster. I recommend that you tell the community what you are trying to do, and then ask with an open mind how the community would accomplish that goal