But in combination with BLT it will work as intended - no rebalancing under the cover.
чт, 13 февр. 2020 г. в 14:39, Alexei Scherbakov < alexey.scherbak...@gmail.com>: > Of course, stable topology will be just a hint. > > Any node can leave at any moment. > > чт, 13 февр. 2020 г. в 14:35, Alexei Scherbakov < > alexey.scherbak...@gmail.com>: > >> 1. Yes >> >> 2. This is right but doesn't sound like a bug. The rebalancing will be >> finished before releasing syncFut and partitions will contain all necessary >> data (but are still in moving state). >> >> 3. No, local node doesn't wait the rebalancing on all grid nodes. >> >> Actually, I think SYNC mode should be dropped as well. Instead we must >> provide the convenient public API to wait for "stable" topology. >> >> >> чт, 13 февр. 2020 г. в 14:09, Maxim Muzafarov <mmu...@apache.org>: >> >>> Pavel, >>> >>> It's still a big question regarding SYNC rebalance mode. Here is my >>> thoughts. >>> >>> 1. Yes, we must rebalance such caches prior to ASYNC one (if the >>> rebalanceOrder configuration will be removed). >>> >>> 2. When persistence is enabled and when WAL is disabled (on the first >>> rebalance start), I think we should finish syncFuture only on >>> checkpoint like we are enabling the WAL state for cache group and >>> simultaneously owning all MOVING partitions. But currently, I've seen >>> that syncFuture finishes when there are no remaining partitions left >>> [1]. >>> Is it correct? Seems like a bug. >>> >>> 3. In my understanding, a new local node can start only when ALL SYNC >>> cache groups have been fully rebalanced on ALL nodes, right? But how >>> about late affinity assignment here? It seems that SYNC caches will be >>> rebalanced locally on the node, the node will start, but other nodes >>> still think this node is not operational (late affinity assignment not >>> occurred yet). >>> >>> >>> [1] >>> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/distributed/dht/preloader/GridDhtPartitionDemander.java#L1561 >>> >>> On Thu, 13 Feb 2020 at 12:57, Pavel Pereslegin <xxt...@gmail.com> wrote: >>> > >>> > > +1 to deprecate rebalanceOrder and remove related functionality, >>> > Meant to "rework related functionality" not "remove". >>> > >>> > чт, 13 февр. 2020 г. в 12:47, Pavel Pereslegin <xxt...@gmail.com>: >>> > > >>> > > Hello, >>> > > >>> > > +1 to deprecate rebalanceOrder and remove related functionality, >>> > > should we create a separate ticket for this? >>> > > >>> > > Btw, as I understand, SYNC mode is only useful for in-memory caches, >>> > > because when persistence is enabled (and WAL is disabled during >>> > > rebalancing), even "ignite-sys-cache" owns partitions only after all >>> > > cache groups are rebalanced. Thus, even utility cache is still >>> > > inoperable after node startup when persistence is enabled. Do we >>> > > really need to wait for SYNC caches when a node starts with enabled >>> > > persistence or should we enabled WAL for SYNC-caches? >>> > > >>> > > чт, 13 февр. 2020 г. в 11:13, Ivan Rakov <ivan.glu...@gmail.com>: >>> > > > >>> > > > Hello, >>> > > > >>> > > > +1 from me for rebalance delay deprecation. >>> > > > I can imagine only one actual case for this option: prevent >>> excessive load >>> > > > on the cluster in case of temporary short-term topology changes >>> (e.g. node >>> > > > is stopped for a while and then returned back). >>> > > > Now it's handled by baseline auto adjustment in a much more >>> correct way: >>> > > > partitions are not reassigned within a maintenance interval >>> (unlike with >>> > > > the rebalance delay). >>> > > > I also don't think that ability to configure rebalance delay per >>> cache is >>> > > > crucial. >>> > > > >>> > > > > rebalanceOrder is also useless, agreed. >>> > > > +1 >>> > > > Except for one case: we may want to rebalance caches with >>> > > > CacheRebalanceMode.SYNC first. But anyway, this behavior doesn't >>> require a >>> > > > separate property to be enabled. >>> > > > >>> > > > On Wed, Feb 12, 2020 at 4:54 PM Alexei Scherbakov < >>> > > > alexey.scherbak...@gmail.com> wrote: >>> > > > >>> > > > > Maxim, >>> > > > > >>> > > > > rebalanceDelay was introduced before the BLT appear in the >>> product to solve >>> > > > > scenarios which are now solved by BLT. >>> > > > > >>> > > > > It's pointless for me having it in the product since BLT was >>> introduced. >>> > > > > >>> > > > > I do not think delaying rebalancing per cache group has any >>> meaning. I >>> > > > > cannot image any reason for it. >>> > > > > >>> > > > > rebalanceOrder is also useless, agreed. >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > ср, 12 февр. 2020 г. в 16:19, Maxim Muzafarov <mmu...@apache.org >>> >: >>> > > > > >>> > > > > > Alexey, >>> > > > > > >>> > > > > > Why do you think delaying of historical rebalance (on BLT node >>> join) >>> > > > > > for particular cache groups is not the real world use case? >>> Probably >>> > > > > > the same topic may be started on user-list to collect more use >>> cases >>> > > > > > from real users. >>> > > > > > >>> > > > > > In general, I support reducing the number of available >>> rebalance >>> > > > > > configuration parameters, but we should do it really carefully. >>> > > > > > I can also propose - rebalanceOrder param for removing. >>> > > > > > >>> > > > > > On Wed, 12 Feb 2020 at 15:50, Alexei Scherbakov >>> > > > > > <alexey.scherbak...@gmail.com> wrote: >>> > > > > > > >>> > > > > > > Maxim, >>> > > > > > > >>> > > > > > > In general rebalanceDelay is used to delay/disable rebalance >>> then >>> > > > > > topology >>> > > > > > > is changed. >>> > > > > > > Right now we have BLT to avoid unnecesary rebalancing when >>> topology is >>> > > > > > > changed. >>> > > > > > > If a node left from cluster topology no rebalancing happens >>> until the >>> > > > > > node >>> > > > > > > explicitly removed from baseline topology. >>> > > > > > > >>> > > > > > > I would like to know real world scenarios which can not be >>> covered by >>> > > > > BLT >>> > > > > > > configuration. >>> > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > ср, 12 февр. 2020 г. в 15:16, Maxim Muzafarov < >>> mmu...@apache.org>: >>> > > > > > > >>> > > > > > > > Alexey, >>> > > > > > > > >>> > > > > > > > > All scenarios where rebalanceDelay has meaning are >>> handled by >>> > > > > > baseline >>> > > > > > > > topology now. >>> > > > > > > > >>> > > > > > > > Can you, please, provide more details here e.g. the whole >>> list of >>> > > > > > > > scenarios where rebalanceDelay is used and how these >>> handled by >>> > > > > > > > baseline topology? >>> > > > > > > > >>> > > > > > > > Actually, I doubt that it covers exactly all the cases due >>> to >>> > > > > > > > rebalanceDelay is a "per cache group property" rather than >>> "baseline" >>> > > > > > > > is meaningful for the whole topology. >>> > > > > > > > >>> > > > > > > > On Wed, 12 Feb 2020 at 12:58, Alexei Scherbakov >>> > > > > > > > <alexey.scherbak...@gmail.com> wrote: >>> > > > > > > > > >>> > > > > > > > > I've meant baseline topology. >>> > > > > > > > > >>> > > > > > > > > ср, 12 февр. 2020 г. в 12:41, Alexei Scherbakov < >>> > > > > > > > > alexey.scherbak...@gmail.com>: >>> > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > > V.Pyatkov >>> > > > > > > > > > >>> > > > > > > > > > Doesn't rebalance topology solves it ? >>> > > > > > > > > > >>> > > > > > > > > > ср, 12 февр. 2020 г. в 12:31, V.Pyatkov < >>> vldpyat...@gmail.com>: >>> > > > > > > > > > >>> > > > > > > > > >> Hi, >>> > > > > > > > > >> >>> > > > > > > > > >> I am sure we can to reduce this ability, but do not >>> completely. >>> > > > > > > > > >> We can use rebalance delay for disable it until >>> manually >>> > > > > > triggered. >>> > > > > > > > > >> >>> > > > > > > > > >> CacheConfiguration#setRebalanceDelay(-1) >>> > > > > > > > > >> >>> > > > > > > > > >> It may helpful for cluster where can not allow >>> performance drop >>> > > > > > from >>> > > > > > > > > >> rebalance at any time. >>> > > > > > > > > >> >>> > > > > > > > > >> >>> > > > > > > > > >> >>> > > > > > > > > >> -- >>> > > > > > > > > >> Sent from: >>> > > > > http://apache-ignite-developers.2346864.n4.nabble.com/ >>> > > > > > > > > >> >>> > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > > > -- >>> > > > > > > > > > >>> > > > > > > > > > Best regards, >>> > > > > > > > > > Alexei Scherbakov >>> > > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > >>> > > > > > > > > -- >>> > > > > > > > > >>> > > > > > > > > Best regards, >>> > > > > > > > > Alexei Scherbakov >>> > > > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > > -- >>> > > > > > > >>> > > > > > > Best regards, >>> > > > > > > Alexei Scherbakov >>> > > > > > >>> > > > > >>> > > > > >>> > > > > -- >>> > > > > >>> > > > > Best regards, >>> > > > > Alexei Scherbakov >>> > > > > >>> >> >> >> -- >> >> Best regards, >> Alexei Scherbakov >> > > > -- > > Best regards, > Alexei Scherbakov > -- Best regards, Alexei Scherbakov
