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
