ignite-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ilya Kasnacheev <ilya.kasnach...@gmail.com>
Subject Re: Ignite native persistence and replicated caches - should it even be possible?
Date Mon, 17 Dec 2018 14:13:30 GMT

I'm not completely sure but persistent REPLICATED cache is the same as

It means that every node will have a copy of data, but it has to be in BLT
to be used.

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

View raw message