ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Scherbakov <alexey.scherbak...@gmail.com>
Subject Re: Data vanished from cluster after INACTIVE/ACTIVE switch
Date Tue, 04 Feb 2020 07:58:00 GMT
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.scherbakoff@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.goncharuk@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 <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
>> > >
>> >
>>
>
>
> --
>
> Best regards,
> Alexei Scherbakov
>


-- 

Best regards,
Alexei Scherbakov

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