Alexey Goncharuk, I see no issues with "lost" partitions. The same is possible right now in persistence mode. Node can be killed and data erased while grid is deactivated.
After re-join it should rebalance itself from existing owners (if any exists). вт, 4 февр. 2020 г. в 10:54, Alexei Scherbakov <alexey.scherbak...@gmail.com >: > Folks, > > For a long time we have a flag [1] > > It does almost what we want here. > > I suggest to make this behavior default and rework it to keep data in > memory as well (we already have special "recovery" mode for caches). > > > [1] org.apache.ignite.IgniteSystemProperties#IGNITE_REUSE_MEMORY_ON_DEACTIVATE > > > > пн, 3 февр. 2020 г. в 18:47, Alexey Goncharuk <alexey.goncha...@gmail.com > >: > >> I do not mind making this change if we explicitly and clearly define what >> 'new inactive state' means. What should happen if a partition is lost in >> inactive state? What if such node joins back the cluster after? Etc. >> >> пт, 31 янв. 2020 г. в 20:57, Denis Magda <dma...@apache.org>: >> >> > Back up Ivan's opinion here. Initially, the activation/deactivation was >> > created for the baseline topology designed for cases with native >> > persistence. My thinking was that the mechanism itended to prevent data >> > inconsistencies while nodes with data on the disk will be in the >> process of >> > joining the cluster. >> > >> > Artem, could you please update the docs bringing this to the attention >> of >> > the user community? >> > https://issues.apache.org/jira/browse/IGNITE-12615 >> > >> > AG, what if we don't purge data from memory at least for the caches not >> > backed by the native persistence? Is this a big deal? We can certainly >> put >> > this off by my guts feel we'll return to this question sooner or later. >> > >> > - >> > Denis >> > >> > >> > On Fri, Jan 31, 2020 at 2:17 AM Ivan Pavlukhin <vololo...@gmail.com> >> > wrote: >> > >> > > For me it looks like some coincidence effect. I understand that we get >> > > such behavior because deactivation works the same way as for >> > > persistent caches. Was cluster activation/deactivation designed and >> > > described for in-memory caches? Current behavior sounds for me a as >> > > big risk. I expect a lot of upset users unexpectedly purged all their >> > > data. >> > > >> > > пт, 31 янв. 2020 г. в 00:00, Alexey Goncharuk < >> > alexey.goncha...@gmail.com >> > > >: >> > > > >> > > > Because originally the sole purpose of deactivation was resource >> > > > deallocation. >> > > > >> > > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <dma...@apache.org>: >> > > > >> > > > > Such a revelation for me that data is purged from RAM if someone >> > > > > deactivates the cluster. Alex, do you remember why we decided to >> > > implement >> > > > > it this way initially? >> > > > > >> > > > > - >> > > > > Denis >> > > > > >> > > > > >> > > > > On Thu, Jan 30, 2020 at 2:09 AM Alexey Goncharuk < >> > > > > alexey.goncha...@gmail.com> >> > > > > wrote: >> > > > > >> > > > > > I agree on CLI and JMX because those interfaces can be used by a >> > > system >> > > > > > administrator and can be invoked by mistake. >> > > > > > >> > > > > > As for the Java API, personally, I find it strange to add >> 'force' >> > or >> > > > > > 'confirm' flags to it because it is very unlikely that such an >> > > invocation >> > > > > > is done by mistake. Such mistakes are caught during the testing >> > > phase and >> > > > > > developers will end up hard-coding 'true' as a flag anyways. >> > > > > > >> > > > > >> > > >> > > >> > > >> > > -- >> > > Best regards, >> > > Ivan Pavlukhin >> > > >> > >> > > > -- > > Best regards, > Alexei Scherbakov > -- Best regards, Alexei Scherbakov
