I'm afraid, description of page-based eviction in documentation is not
Page-based eviction (RANDOM_LRU or RANDOM_2_LRU) can be activated only
if persistent store is /disabled/. It defines algorithm for choosing
page in RAM to remove all contents completely.
On the other hand, when persistent store is /enabled/, eviction from RAM
to disk is enabled by default and is not customizable by user. So answer
to first question 1 is no - you shouldn't specify anything in
configuration to make disk eviction work.
About question 2 - You will lose partition after crash of N1. Losing of
partition is always undesirable scenario. By default, partition will be
reset, and you can't say for sure which version of partition (old from
disk or new from another node) will be resolved as actual after join of N1.
Safe solution - configure backup nodes. Your data will be safe at N3.
Another safe solution - set safe partition loss policy (e.g.
PartitionLossPolicy.READ_WRITE_SAFE). All reads/writes from lost
partition will throw an exception until crashed node N1 returns to the
topology. After that, "1" entry will be recovered.
Thanks for raising this topic, we'll fix the documentation soon.
On 10.08.2017 5:38, userx wrote:
I was going through the documentation of durable memory at
As per the documentation, durable memory comes into picture when
PersistentStore configuration is enabled. Now durable memory uses both
RAM(hot data) and disk (superset). When the RAM part reaches a threshold
(80% by default as per the documentation), the durable data retains only hot
data in RAM and rest on the disk.
So does that mean that there is a default eviction policy which comes into
existence ? Or does the user explicitly has to mention the same in
configuration ? What happens if he does not mention the eviction policy in
Suppose there are 2 nodes N1 (different physical box) and N2 (different
physical box) and the data is distributed in PARTITIONED mode and persistent
store is enabled.
Here is the example of entries
Suppose N1 crashes and goes down and does not come up at all for say 5
hours. Is "1" retrievable at all during that time if N1 went down after an
entry to its WAL file or we loose N1 ? If say the entry was not able to be
made in WAL file and should we have configured a back up as N3 (different
physical box), would it have saved "1" ?
View this message in context:
Sent from the Apache Ignite Users mailing list archive at Nabble.com.