Ilya, thank you very much for your response!
Kamil Mišúth
On 2018-12-17 15:13, Ilya Kasnacheev wrote:
> Hello!
>
> I'm not completely sure but persistent REPLICATED cache is the same as
> PARTITIONED with MAXINT backups.
>
> It means that every node will have a copy of data, but it has to be in
> BLT to be used.
>
> Regards,
>
> --
>
> Ilya Kasnacheev
>
> пн, 17 дек. 2018 г. в 14:46, kimec.ethome.sk [1]
> <kimec@ethome.sk>:
>
>> Hi all,
>>
>> Could somebody confirm my conclusion below?
>>
>> It seems it is possible to declare a REPLICATED cache configuration
>> for
>> caches that are mapped to a data region backed by the native
>> persistence
>> layer.
>> Ignite does not complain about this configuration and boots happily.
>>
>> Yet, after cluster restart, during runtime, the cache behaves as if
>> it
>> was PARTITIONED - since the configuration says REPLICATED, Ignite
>> will
>> not attempt to reload the data from the node actually owning them (a
>>
>> node that has the data stored on disk from before cluster restart).
>>
>> Net effect is that a node that is not a member of a baseline
>> topology
>> will report the cache contains no data for a given key even though
>> persisted data actually do exist in the cluster (but on a separate
>> node).
>>
>> The documentation is not very clear on whether REPLICATED caches are
>>
>> supported by native persistence or not, but reading between the
>> lines[1], I guess the only supported use case for native persistence
>> is
>> PARTITIONED cache.
>>
>> If that is so, I would expect the node declaring such a cache
>> configuration to fail fast during startup. Or maybe the
>> documentation
>> should state this more clearly. It is not very intuitive, to say the
>>
>> least.
>>
>> Anyway, could somebody kindly confirm my suspicion? Thank you!
>>
>> Kamil Mišúth
>>
>> [1]
>>
> https://apacheignite.readme.io/v2.7/docs/distributed-persistent-store#section-overview
>
>
> Links:
> ------
> [1] http://kimec.ethome.sk
|