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 <[email protected]>: > 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 >
