> identify all backup partitions on a given clusternode which are backups of primary partitions on another cluster node > I am running on Node A and want to know which partitions from Node B does Node A have a backup for
If I understood this correctly, the following should work: IClusterNode a, b; // Given known nodes A and B int[] bPrimary = aff.GetPrimaryPartitions(b); int[] aBackup = aff.GetBackupPartitions(a); var backupsOfBOnA = aBackup.Intersect(bPrimary); > which feels like it might be slow Affinity operations should be relatively quick - it is just some basic math. You can also cache the results between topology version changes (check ICluster.TopologyVersion). Let me know if this helps, Pavel On Thu, Mar 4, 2021 at 5:03 AM Raymond Wilson <[email protected]> wrote: > The ICacheAffinity interface provides a collection of methods to determine > partitions from keys, and nodes from partitions. > > The GetBackupPartitions() method will return all partitions for which the > given clusternode is a backup. This is handy if you want to identify backup > partitions on a node. > > /// <summary> > /// Gets partition ids for which nodes of the given projection has > backup > /// ownership. > /// </summary> > /// <param name="n">Node.</param> > /// <returns>Partition ids for which given projection has backup > ownership.</returns> > int[] GetBackupPartitions(IClusterNode n); > > What I would like to do is something similar, which is to identify all > backup partitions on a given clusternode which are backups of primary > partitions on another cluster node. > > ie: I am running on Node A and want to know which partitions from Node B > does Node A have a backup for. > > The use case here is broadly this "I broadcast a request to a topology > projection of nodes, one of which may not be available at the given time > (so won't be routed to it). The business logic on each node coordinates > processing of the request against the partitions that node owns. If that > node owns backup partitions from the node that is not available, it should > also process those partitions to provide the correct result". > > I know Ignite will do this for me if I provide a vector of keys to an > affinity based call method (and we do have other request paths that do > similar things), however that's not practical in this particular example > for other reasons (eg: a key vector representation of the request could be > truly large), so we need to address this in the request processing > application logic itself. > > We provide our own affinity function for the caches involved, so can > probably build these vectors at that time, but they would not be exposable > through the ICacheAffinity interface. > > The MapPartitionToPrimaryAndBackups(int part) looks like it would provide > the required information, but would need to be called for every partition > in the cache, which feels like it might be slow. > > Thoughts? > > Thanks, > Raymond. > > > -- > <http://www.trimble.com/> > Raymond Wilson > Solution Architect, Civil Construction Software Systems (CCSS) > 11 Birmingham Drive | Christchurch, New Zealand > [email protected] > > > <https://worksos.trimble.com/?utm_source=Trimble&utm_medium=emailsign&utm_campaign=Launch> >
