You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by Anil <an...@gmail.com> on 2016/12/14 11:48:32 UTC
Ignite cluster
HI,
how ignite cluster internally behaves when a node disconnects from cluster ?
Lets say A , B, C are three nodes formed ignite cluster.
When A disconnects from the cluster, ignite instance on A is still run ?
now will there be two clusters A , B & C ?
Please clarify.
Thanks
Re: Ignite cluster
Posted by vkulichenko <va...@gmail.com>.
Tejas,
You can send a closure to server node and iterate through local data using
IgniteCache.localEntries() method. This should give you a clear picture.
BTW, is this the correct thread? Looks like you posted in a wrong one by
mistake.
-Val
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-cluster-tp9527p9812.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Ignite cluster
Posted by Tejashwa Kumar Verma <te...@gmail.com>.
Hi,
Ok once data is getting collocated . how can we verify that data has been
loaded on same node ?
can we check dump loaded memory data in file?
Thanks & Regards
Tejas
On Thu, Dec 29, 2016 at 9:32 AM, Anil <an...@gmail.com> wrote:
> Understood.
> But adding some kind of merge policy (keeping latest entry and ignore
> other copies) and allowing node rejoin may be good option.
>
> Thanks.
>
> On 28 December 2016 at 21:33, vkulichenko <va...@gmail.com>
> wrote:
>
>> Hi Anil,
>>
>> Because that's how it works :) Main reason behind this is to ensure data
>> consistency. When you restart the node, its memory is cleaned up and it
>> joins as a brand new node. Rejoin with existing data will require
>> additional
>> processing and in general case will not guarantee consistency.
>>
>> Makes sense?
>>
>> -Val
>>
>>
>>
>> --
>> View this message in context: http://apache-ignite-users.705
>> 18.x6.nabble.com/Ignite-cluster-tp9527p9784.html
>> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>>
>
>
Re: Ignite cluster
Posted by Anil <an...@gmail.com>.
Understood.
But adding some kind of merge policy (keeping latest entry and ignore other
copies) and allowing node rejoin may be good option.
Thanks.
On 28 December 2016 at 21:33, vkulichenko <va...@gmail.com>
wrote:
> Hi Anil,
>
> Because that's how it works :) Main reason behind this is to ensure data
> consistency. When you restart the node, its memory is cleaned up and it
> joins as a brand new node. Rejoin with existing data will require
> additional
> processing and in general case will not guarantee consistency.
>
> Makes sense?
>
> -Val
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Ignite-cluster-tp9527p9784.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>
Re: Ignite cluster
Posted by vkulichenko <va...@gmail.com>.
Hi Anil,
Because that's how it works :) Main reason behind this is to ensure data
consistency. When you restart the node, its memory is cleaned up and it
joins as a brand new node. Rejoin with existing data will require additional
processing and in general case will not guarantee consistency.
Makes sense?
-Val
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-cluster-tp9527p9784.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Ignite cluster
Posted by Anil <an...@gmail.com>.
Thank you val.
I am still not clear why node can't join the topology when network issues
resolved. Thanks.
On 28 December 2016 at 00:29, vkulichenko <va...@gmail.com>
wrote:
> Anil,
>
> NOOP means that you have to create your own custom listener for
> EVT_NODE_SEGMENTED event, so it can't be a default policy. Doing nothing
> will not work, because node can't rejoin the topology after segmentation.
> Full node restart is needed anyway.
>
> -Val
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Ignite-cluster-tp9527p9762.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>
Re: Ignite cluster
Posted by vkulichenko <va...@gmail.com>.
Anil,
NOOP means that you have to create your own custom listener for
EVT_NODE_SEGMENTED event, so it can't be a default policy. Doing nothing
will not work, because node can't rejoin the topology after segmentation.
Full node restart is needed anyway.
-Val
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-cluster-tp9527p9762.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Ignite cluster
Posted by Anil <an...@gmail.com>.
Hi Val,
Having two independently running clusters is fine with running ignite cache
in each cluster.
But I see cache is stopped because of network segmentation.
*Following the response to one of the query [1] -*
*Call chain:*
*org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.DiscoveryWorker#onSegmentation*
*org.apache.ignite.internal.managers.discovery.GridDiscoveryManager#stopNode*
*org.apache.ignite.Ignition#stop(java.lang.String, boolean)*
*You could change IgniteConfiguration.setSegmentationPolicy()
to SegmentationPolicy.NOOP, so the node will not be stopped upon
segmentation (the default value is STOP).*
I would feel NOOP as default network segmentation policy is better option
than STOP. Network segmentation is just temporary problem and independent
clusters can join as one cluster once is network is good. So STOP not makes
sense in this case.
What do you say ? thanks
1. http://apache-ignite-users.70518.x6.nabble.com/Cache-stopped-td9503.html
Thanks.
On 23 December 2016 at 00:29, vkulichenko <va...@gmail.com>
wrote:
> Anil,
>
> Nothing is stopped. Once again, in case of segmentation you will have two
> independently running clusters. And in of the previous messages you told
> that this is desirable behavior for you as you have a read-only use case.
> Am
> I missing something? Did you run any test that gave different results?
>
> -Val
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Ignite-cluster-tp9527p9707.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>
Re: Ignite cluster
Posted by vkulichenko <va...@gmail.com>.
Anil,
Nothing is stopped. Once again, in case of segmentation you will have two
independently running clusters. And in of the previous messages you told
that this is desirable behavior for you as you have a read-only use case. Am
I missing something? Did you run any test that gave different results?
-Val
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-cluster-tp9527p9707.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Ignite cluster
Posted by Anil <an...@gmail.com>.
Hi Val,
I agree with you on "separate clusters running". but ignite is stopped.
Separate clusters has no meaning. agree?
Thanks
On 22 December 2016 at 00:25, vkulichenko <va...@gmail.com>
wrote:
> Anil,
>
> All this is very use case specific. STOP is used by default because it's
> the
> safest option and gives more control. However, it does imply some manual
> operations to resolve the segmentation.
>
> In any case, above is about the feature that is available only in GridGain,
> not in Ignite. In Ignite you will just have two separate clusters running,
> which sounds like the behavior you're looking for.
>
> -Val
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Ignite-cluster-tp9527p9686.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>
Re: Ignite cluster
Posted by vkulichenko <va...@gmail.com>.
Anil,
All this is very use case specific. STOP is used by default because it's the
safest option and gives more control. However, it does imply some manual
operations to resolve the segmentation.
In any case, above is about the feature that is available only in GridGain,
not in Ignite. In Ignite you will just have two separate clusters running,
which sounds like the behavior you're looking for.
-Val
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-cluster-tp9527p9686.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Ignite cluster
Posted by Anil <an...@gmail.com>.
Thanks Val.
But the default STOP option not looks correct. There is always chance of
rejoining of cluster.
But if ignite cache is stopped because of segmentation, rejoin has no
meaning.
Creating different clusters still fine as long as cache is not stopped in
case of network segmentation.
is there way to change the default value without setting network
segmentation policy?
Thanks
On 20 December 2016 at 23:11, vkulichenko <va...@gmail.com>
wrote:
> Ignite doesn't have full segmentation resolution support out of the box.
> With
> Ignite you will always end up with two independent working cluster in case
> of segmentation. You will then have to restart on of these clusters, but if
> there were updates on the restarted cluster after the segmentation, they
> will be lost. The link provided above is for GridGain which has additional
> enterprise feature that allows to stop or restart on of the clusters
> automatically right after the segmentation, so there is no time frame with
> two cluster and you never lose updates.
>
> -Val
>
>
>
> --
> View this message in context: http://apache-ignite-users.
> 70518.x6.nabble.com/Ignite-cluster-tp9527p9649.html
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>
Re: Ignite cluster
Posted by vkulichenko <va...@gmail.com>.
I'm not aware of such plans.
-Val
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-cluster-tp9527p9915.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Ignite cluster
Posted by ghughal <ba...@gmail.com>.
vkulichenko wrote
> Ignite doesn't have full segmentation resolution support out of the box.
> With Ignite you will always end up with two independent working cluster in
> case of segmentation. You will then have to restart on of these clusters,
> but if there were updates on the restarted cluster after the segmentation,
> they will be lost. The link provided above is for GridGain which has
> additional enterprise feature that allows to stop or restart on of the
> clusters automatically right after the segmentation, so there is no time
> frame with two cluster and you never lose updates.
>
> -Val
Val - are there any plans of moving this feature to ignite?
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-cluster-tp9527p9912.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Ignite cluster
Posted by vkulichenko <va...@gmail.com>.
Ignite doesn't have full segmentation resolution support out of the box. With
Ignite you will always end up with two independent working cluster in case
of segmentation. You will then have to restart on of these clusters, but if
there were updates on the restarted cluster after the segmentation, they
will be lost. The link provided above is for GridGain which has additional
enterprise feature that allows to stop or restart on of the clusters
automatically right after the segmentation, so there is no time frame with
two cluster and you never lose updates.
-Val
--
View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Ignite-cluster-tp9527p9649.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Re: Ignite cluster
Posted by Anil <an...@gmail.com>.
Can someone point me to the ignite xml configuration for network
segmentation ?
i see IgniteConfiguration property names for network segmentation and
setting methods are different :)
Thanks
On 14 December 2016 at 18:20, Anil <an...@gmail.com> wrote:
> Hi Anton,
>
> Thank you very much.
>
>
>
> On 14 December 2016 at 17:49, Anton Vinogradov <av...@apache.org> wrote:
>
>> Anil,
>>
>> This situation described here https://gridgain.readme.i
>> o/docs/network-segmentation
>>
>>
>>
>> On Wed, Dec 14, 2016 at 2:48 PM, Anil <an...@gmail.com> wrote:
>>
>>> HI,
>>>
>>> how ignite cluster internally behaves when a node disconnects from
>>> cluster ?
>>>
>>> Lets say A , B, C are three nodes formed ignite cluster.
>>>
>>> When A disconnects from the cluster, ignite instance on A is still run ?
>>> now will there be two clusters A , B & C ?
>>>
>>> Please clarify.
>>>
>>> Thanks
>>>
>>
>>
>
Re: Ignite cluster
Posted by Anil <an...@gmail.com>.
Hi Anton,
Thank you very much.
On 14 December 2016 at 17:49, Anton Vinogradov <av...@apache.org> wrote:
> Anil,
>
> This situation described here https://gridgain.readme.
> io/docs/network-segmentation
>
>
>
> On Wed, Dec 14, 2016 at 2:48 PM, Anil <an...@gmail.com> wrote:
>
>> HI,
>>
>> how ignite cluster internally behaves when a node disconnects from
>> cluster ?
>>
>> Lets say A , B, C are three nodes formed ignite cluster.
>>
>> When A disconnects from the cluster, ignite instance on A is still run ?
>> now will there be two clusters A , B & C ?
>>
>> Please clarify.
>>
>> Thanks
>>
>
>
Re: Ignite cluster
Posted by Anton Vinogradov <av...@apache.org>.
Anil,
This situation described here
https://gridgain.readme.io/docs/network-segmentation
On Wed, Dec 14, 2016 at 2:48 PM, Anil <an...@gmail.com> wrote:
> HI,
>
> how ignite cluster internally behaves when a node disconnects from cluster
> ?
>
> Lets say A , B, C are three nodes formed ignite cluster.
>
> When A disconnects from the cluster, ignite instance on A is still run ?
> now will there be two clusters A , B & C ?
>
> Please clarify.
>
> Thanks
>
Re: Ignite cluster
Posted by luqmanahmad <lu...@gmail.com>.
See [1] for free network segmentation plugin
[1] https://github.com/luqmanahmad/ignite-plugins
<https://github.com/luqmanahmad/ignite-plugins>
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/