synchronous replication in hazelcast

Question

We are evaluating Hazelcast for one our use cases and i have a doubt regarding the replication in hazelcast.

It is mentioned in http://docs.hazelcast.org/docs/latest-development/manual/html/Distributed_Data_Structures/Map/Backing_Up_Maps.html that "Backup operations are synchronous, so when a map.put(key, value)returns, it is guaranteed that the map entry is replicated to one other member".

But in another page http://docs.hazelcast.org/docs/latest-development/manual/html/Consistency_and_Replication_Model.html, it is mentioned "Two types of backup replication are available: sync and async. Despite what their names imply, both types are still implementations of the lazy (async) replication model".

Both these statements look a bit contradictory. Can someone please throw some light onto this?

Is replication in Hazelcast truly synchronous? I need to have the values updated in both the owner and backup nodes together.

Answer 1

The explanation in here is more correct. In the context of CAP theorem, Hazelcast is an AP product. Thus, Best-Effort Consistency is aimed on replication and both sync and async backups are implementations of the lazy replication model. As it is explained in the page; the difference between two options is;

• in sync backups, the caller block until backup updates are applied by backup replicas and acknowledgments are sent back to the caller
• the async backups works as fire & forget.

Below, please see the part from Hazelcast Reference Manual:

Hazelcast's replication technique enables Hazelcast clusters to offer high throughput. However, due to temporary situations in the system, such as network interruption, backup replicas can miss some updates and diverge from the primary. Backup replicas can also hit long GC pauses or VM pauses, and fall behind the primary, which is a situation called as replication lag. If a Hazelcast partition primary replica member crashes while there is a replication lag between itself and the backups, strong consistency of the data can be lost.