ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexey Goncharuk <alexey.goncha...@gmail.com>
Subject Re: Data vanished from cluster after INACTIVE/ACTIVE switch
Date Mon, 03 Feb 2020 15:47:20 GMT
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 <dmagda@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 <vololo100@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.goncharuk@gmail.com
> > >:
> > >
> > > Because originally the sole purpose of deactivation was resource
> > > deallocation.
> > >
> > > чт, 30 янв. 2020 г. в 22:13, Denis Magda <dmagda@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.goncharuk@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message