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 <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