Hi Jose, First of you refer to a slide about Data Center Replication, an commercial feature of GridGain. Ignite does not provide such feature. Also, SQL and Cache API could behave different.
You can check how Cache API shows itself in your experiments. CacheAtomicityMode and PartitionLossPolicy (cache configuration options) can change the behavior in respect of consistency. пн, 24 дек. 2018 г. в 09:55, joseheitor <j...@heitorprojects.com>: > > In this GridGain presentation: > > https://www.youtube.com/watch?v=u8BFLDfOdy8&t=1806s > <https://www.youtube.com/watch?v=u8BFLDfOdy8&t=1806s> > > Valentin Kulichenko explains the CAP theorem and states that Apache Ignite > is designed to favour Strong-Consistency (CP) over High-Availability (AP). > > However, in my test case, my system appears to be behaving as an AP system. > Here is my setup: > > 4 partitioned nodes in 2 availability-zones [AZa-1, AZa-2] [AZb-3, AZb-4], > configured as described in this post: > > http://apache-ignite-users.70518.x6.nabble.com/RESOLVED-Cluster-High-Availability-tp25740.html > <http://apache-ignite-users.70518.x6.nabble.com/RESOLVED-Cluster-High-Availability-tp25740.html> > > With 7,000 records loaded into a table in the cluster with JDBC Thin client: > > 1. [OK] I can connect to any node and verify that there are 7,000 records > with a SELECT COUNT(*) > > 2. [OK] If I kill all nodes in AZ-a [AZa-1, AZa-2], and connect to one of > the remaining online nodes in AZ-b, I can still verify that there are 7,000 > records with a SELECT COUNT(*) > > 3. [?] I then kill one of the remaining two nodes in AZ-b and connect to the > single remaining node. Now a SELECT COUNT(*) returns a value of 3,444 > records. > > This seems to illustrate that the partitioning and backup configuration is > working as intended. But if Ignite is strongly-consistent (CP), shouldn't > the final query fail rather than return an inaccurate result (AP)? > > Or am I missing some crucial configuration element(s)? > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ -- Best regards, Ivan Pavlukhin
