many thanks
for last question, I have tried on my laptops and found what I need.
srecon wrote
> Hi,
> Let’s start at the beginning. There is no primary node in Ignite. When we
> say primary node (I will correct the term in the book soon), we mean the
> node that contains the master (prime/primary) copies of the keys or
> partitions.
>
>
> monstereo wrote
>> Especially chapter 4 Architecture deep dive
>>
>> Now:
>> 1) primary node is the node where we do igniteCache.put(2)="any string".
>> I
>> mean node which we put data in to cache is primary node?
>
> If you have a single node cluster, the answer is yes. However, if you have
> a
> multi-node cluster, the answer is NO, because you can execute
> igniteCache.put(2)="any string" command through Ignite thin client (REST,
> Java thin client, etc.,) or the Ignite client node.
> Primary node of the keys (actually Ignite uses partitions to store keys)
> is
> the node that stores a master copy of the key-value.
> In the PARTITIONED mode, Ignite stores data across the entire cluster. In
> this mode, one of the nodes contains master copy of the data and rest of
> the
> nodes contains a backup copy of the same data (depends on BACKUP value
> configuration)
> In the REPLICATED mode, each node contains the same data for the
> particular
> cache.
>
>
> monstereo wrote
>> Especially chapter 4 Architecture deep dive
>>
>> 2) let's say we have primary node(includes some cache datas, cache name
>> cache1), now we create another node, then we take the distributed
>> cache(igniteCache.getOrCreateCache("cache1") and we put new element to
>> the
>> node igniteCache.put(3)="data", now this new node is also primary node?
>
> In the PARTITIONED cache mode, the second node will contain 50% of the
> master copies of the cache named "cache1".
>
>
> monstereo wrote
>> Especially chapter 4 Architecture deep dive
>>
>> 3) I have known that when client node wants to read cache, firstly it
>> reads
>> from primary node. But book says ->
>>
> *
>> * "up to 2.5 version, all read requests from the client node
>> to replicated cache goes
>> through the primary node, which can impact a severe performance issue. It
>> was fixed as
>> a bug20 and resolved in version 2.5"*.
> *
>> That's means, client can read data any backup node?(without going primary
>> node)
>
> Yes, you can explicitly read backup copies of the data, see the method
> CacheConfiguration.isReadFromBackup(). Anyway, it's not recommended
> because
> you may have stale data read (a value has already been updated on primary
> but not updated in backups yet).
>
>
> monstereo wrote
>> Especially chapter 4 Architecture deep dive
>>
>> 4) For data replication book says there are 2 forms ->
> *
>> *Master-slave
>> Peer-to-peer*
> *
>> but there is no explanation for which ignite should use in default. Or
>> how
>> can i
>> force to use one specific form?
>
> Quote from the book "Apache Ignite does not have any master node and
> therefore does not use master-slave replication for distributing data."
>
> Apache Ignite uses peer-to-peer replication strategies, and you don't need
> to specify it explicitly.
>
>
>
> monstereo wrote
>> Especially chapter 4 Architecture deep dive
>>
>> 5) Book says that (for Peer-to-peer)->
> *
>> *The loss of any node does not prevent access to the data store.*
> *
>> Now, let's say I have one node which includes cache store factory xml
>> configuration which updates database or get datas from database.
>> Now, I create another node, but this node has no cache store factoy xml
>> configuration.
>> When node which has cache store factory xml configuration fails, other
>> node(s) will be update database ?
>
> Sorry, I could not get your question, please try to explain the use case
> in
> details.
>
> P.S. I do not always pay attention to Ignite forum. To get a quick
> response,
> please send me any private message or copy the question to
> srecon@
> .
>
> Best regards
> Shamim
>
>
>
> --
> Sent from: http://apache-ignite-users.70518.x6.nabble.com/
--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/
