With regards to multi-field affinity, while you could do that (by putting @AffinityKeyMapped annotation on a complex object), this will require all participating caches to have affinity on all these columns, so this is usually not what users want.
------------------------------
Ilya Kasnacheev
Community Support Specialist
GridGain
------------------------------
Original Message:
Sent: 07-14-2020 04:02 AM
From: Ilya Kasnacheev
Subject: No support for affinity in GridGain whereas Apache provides
Hello!
Persistent clusters operate with READ_WRITE_SAFE PartitionLossPolicy by default:
https://www.gridgain.com/docs/latest/developers-guide/partition-loss-policy?#configuring-partition-loss-policy
This means that operations on partitions which were lost for some time, need their partition loss status reset when baseline nodes come back, You can do that with control.sh utility:
bin/control.sh --cache reset_lost_partitions SQL_CITY_CACHE
Regards,
------------------------------
Ilya Kasnacheev
Community Support Specialist
GridGain
Original Message:
Sent: 07-13-2020 05:48 AM
From: Saikiran Boppudi
Subject: No support for affinity in GridGain whereas Apache provides
Hi Team,
Apache Ignite supports affinity with zero backups whereas GridGain doesn't seem to do so.
Nodes and partitions that were brought down in GridGain were lost and data is not retrievable whereas in Apache Ignite everything worked fine with no extra configuration.
I've documented the set up and steps for the same. Please check and clarify.
Objective - Verifying the data collocation with affinity key, backups as 0 is intentional just to see if functionality is working.
In production cases it would be a number > 1.
Also,
- Does Ignite support the custom affinity key for collocating data using more than one field?
- Are partition policies supported in GridGain different from those supported in Apache Ignite?
------------------------------
Saikiran Boppudi
SSE
Nisum
------------------------------