Search code examples
replicationhazelcast

Is Hazelcast async write transitive?


I am doing some simple benchmarking with Hazelcast to see if it might fit our needs for a distributed data grid. The idea is to have an odd number of servers (eg 5) with '> n/2' replication (eg 3).

With all servers and the client running on my local machine (no network latency) I get the following results:

5 x H/C server (sync backup = 2, async backup = 0); 100 Client Threads : 35,196 puts/second

5 x H/C server (sync backup = 1, async backup = 1); 100 Client Threads : 41,918 puts/second

5 x H/C server (sync backup = 0, async backup = 2); 100 Client Threads : 52,007 puts/second

As expected, async backups allow higher throughput than sync backups. For our use case we would probably opt for the middle option (1x sync and 1x async) as this give us an acceptable balance between resilience and performance.

My question is: If Hazelcast is configured with 1x sync and 1x async, and the node crashes after the sync backup is performed (server returns 'OK' to client and client thread carries on) but before the async backup is performed (so the data is only on one replica and not the second), will the node that received the sync backup pick up the task of the async backup, or will it just wait until the entire cluster re-balances and the 'missing' data from the crashed node is re-distributed from copies? And if the latter, once the cluster re-balances will there be a total of 3 copies of the data, as there would have been if the node hadn't crashed, or will there only be 2 copies because the sync'd node assumes that another node already received its copy?


Solution

  • The partition owner is responsible for creating all backups. In other words: The 1st backup does NOT create a new backup request for the 2nd backup - it's all responsibility of the owner.

    If a member holding a backup replica is stale then anti-entropy mechanism kicks in and the backup partition will be updated to match the owner.

    When a member goes down then the 1st (=sync) backup is eventually promoted to be a new partition owner. It's a responsibility of the new owner to make sure a configured redundancy is honoured - a new backup will be created to make sure there 2 backups as configured.