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 sre...@yandex.ru.

Best regards
  Shamim 



--
Sent from: http://apache-ignite-users.70518.x6.nabble.com/

Reply via email to