Got it, but I do not like the name of the metric, I think it is confusing.
I would provide the following metrics:
- minNumberOfCopies()
- maxNumberOfCopies()
Will this work for you?
D.
On Thu, Nov 23, 2017 at 10:38 PM, Alex Plehanov <plehanov.a...@gmail.com>
wrote:
> We have target redundancy level - 4. If, for some reason, minimal
> redundancy level reached the value of 1, then each next node left the
> cluster may cause data loss or service unavailability.
>
> 2017-11-24 1:31 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:
>
> > Alex,
> >
> > I am really confused. What do you need to know the "minimal partition
> > redundancy" for? What will it give you?
> >
> > D.
> >
> > On Thu, Nov 23, 2017 at 2:25 PM, Alex Plehanov <plehanov.a...@gmail.com>
> > wrote:
> >
> > > Example was in my previous letters: if we have in our cluster for cache
> > > group one partition with 2 copies (1 primary and 1 backup) and other
> > > partitions with 4 copies (1 primary and 3 backups), then minimal
> > partition
> > > redundancy level for this cache group will be 2.
> > >
> > > Maybe code will be more clear than my description, I think it will be
> > > something like that:
> > >
> > > for (int part = 0; part < partitions; part++) {
> > > int partRedundancyLevel = 0;
> > >
> > > for (Map.Entry<UUID, GridDhtPartitionMap> entry :
> > > partFullMap.entrySet()) {
> > > if (entry.getValue().get(part) ==
> > > GridDhtPartitionState.OWNING)
> > > partRedundancyLevel++;
> > > }
> > >
> > > if (partRedundancyLevel < minRedundancyLevel)
> > > minRedundancyLevel = partRedundancyLevel;
> > > }
> > >
> > >
> > > 2017-11-23 4:04 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org>:
> > >
> > > > I think you are talking about the case when cluster temporarily gets
> > into
> > > > unbalanced state and needs to rebalance. However, I am still not sure
> > > what
> > > > this metric would show. Can you provide an example?
> > > >
> > > > D.
> > > >
> > > > On Wed, Nov 22, 2017 at 2:10 PM, Alex Plehanov <
> > plehanov.a...@gmail.com>
> > > > wrote:
> > > >
> > > > > It's not about caches.
> > > > > Each partition has certain amount of copies. Amount of copies may
> > > differ
> > > > > for different partitions of one cache group.
> > > > >
> > > > > This configuration possible:
> > > > > 1) With custom affinity function
> > > > > 2) When nodes left the cluster, till rebalancing is not finished
> > > > >
> > > > >
> > > > >
> > > > > 2017-11-23 0:18 GMT+03:00 Dmitriy Setrakyan <dsetrak...@apache.org
> >:
> > > > >
> > > > > > On Wed, Nov 22, 2017 at 12:39 PM, Alex Plehanov <
> > > > plehanov.a...@gmail.com
> > > > > >
> > > > > > wrote:
> > > > > >
> > > > > > > Hello Dmitriy,
> > > > > > >
> > > > > > > I agree.
> > > > > > >
> > > > > > > By "minimal partition redundancy level for cache group" I mean
> > > > minimal
> > > > > > > number of partition copies among all partitions of this cache
> > > group.
> > > > > > > For example, if we have in our cluster for cache group one
> > > partition
> > > > > > with 2
> > > > > > > copies (1 primary and 1 backup) and other partitions with 4
> > copies
> > > (1
> > > > > > > primary and 3 backups), then minimal partition redundancy level
> > for
> > > > > this
> > > > > > > cache group will be 2.
> > > > > > >
> > > > > >
> > > > > > Such configuration within the same group would be impossible. All
> > > > caches
> > > > > > within the same group have identical total number of partitions
> and
> > > > > > identical number of backups. If that is not the case, then they
> > fall
> > > > into
> > > > > > different groups.
> > > > > >
> > > > > > D.
> > > > > >
> > > > >
> > > >
> > >
> >
>
