Hazelcast Data Partition replica
Rakesh Sharma
Tom OConnell
Hi –
Yes, Hazelcast can have multiple backup copies.
You’re correct on the partitioning – the ‘hash result’ you mention is the java hashCode() value from the serialized byte-array representation of the key. As this will not change, the partition assignment will not change – although the partition may migrate, based on members joining or leaving the cluster.
There’s one error in your example – for each partition set, there’s a single primary and 0 to many backup copies (backup partitions). In your example below, either M1 or M3 would have the primary – not both.
You don’t need to – and probably shouldn’t – have backups on each member, although you may, should you so choose.
In your example – a backup count of 3 and 271 partitions across 4 members – each member will have 67 (or 68) primary partitions and 201 (or 202) backup partitions. Each of the primary partitions will have a backup on each of the other members (3 backups across 3 other members). With the loss of a member, you’d have 271 across the surviving 3 members, so 90 (or 91) primary partitions per and double that in backups. The 3 member-cluster, though, will only support 2 backup copies – unless/until the lost member rejoins, hence ‘double’, not triple.
Each partition has one (by default) or the configured number of backups. Except in the case of a two-member cluster – no member is ever the mirror of another – the backup partitions are spread across the cluster. This helps minimize the impact of a member loss.
So, with the loss of a second member (of the original 4), there will be a single backup for each primary partition. This is the sole case where one member is the logical mirror of the other.
Note that as each key-value pair is written to a map, it will be copied – either sync or async, based on your config – to backup partition(s) on other members. For synch-backups, the backup(s) all exist, before control is returned to the caller.
Note that you can configure either or both synchronous and asynchronous backups. This is rarely if ever, required.
As members join and exit, though, the member to partition assignments will change. When a member terminates, each of its partitions will have a backup on another member promoted to primary and a new backup will be created – if this is possible, given your cluster-size and backup-count. In no case will there ever be two backups of a single partition on one member. So, with the simultaneous loss of two members, from a cluster of four – the backup count of 3 will not be maintained until the members rejoin. Note that when the members re-join, they are dynamically assigned partitions from the existing members; we would not expect to have the newly rejoined member holding the same partitions as before the exit.
As each backup is a full copy of your data-set, 3 backup copies (4 copies, total) is kind of memory-expensive. This may be warranted, but consider the uptime of your JVMs – ideally from your own production history. Many clusters stay up for months between maintenance activities. In light of this, fewer backups may be more reasonable – it is not required by Hazelcast, that each key resides within each member. Configuring persistence may be a good alternative to this backup count.
Please let me know if this helped.
Cheers
Tom
Rakesh Sharma
By default, Hazelcast creates a single copy/replica of each partition.
The following is an illustration of the partition replica distributions in a Hazelcast cluster with four members with default settings. Since we have 271 partitions .Each member will have 68/69 primary partitions and 68/69 replica partitions.
m1 - Primary Partitions [P1-P68] and Replica Partitions of [P137-P204]
m2 - Primary Partitions [P69-P136] and Replica Partitions of [P205-P271]
m3- Primary Partitions [P137-P204] and Replica Partitions of [P1-P68]
m4 - Primary Partitions [P205-P271] and and Replica Partitions of [
P69-P136 ]
What I am trying to under is it possible to have 2 replica partitions on each member and how to achieve it? I want 2 replica partitions.271x2=542 replica partitions on each member.
m1 - Primary Partitions [P1-P68] and Replica Partitions of [P137-P204], [P205-P271]
m2 - Primary Partitions [P69-P136] and Replica Partitions of [P205-P271], [P1-P68]
m3- Primary Partitions [P137-P204] and Replica Partitions of [P1-P68],[ P69-P136 ]
m4 - Primary Partitions [P205-P271] and and Replica Partitions of [ P69-P136 ],[P137-P204]
Am I just talking about memory chunks(Partitions replica) only first.
I will get into Map item replicas next.
Thanks,
Rakesh
Tom OConnell
Hi Rakesh -
You're correct about 271 partitions across four members. The partition numbers may or may not be what you described, but we all understand that the actual partition numbers really don't matter.
Replicated partitions serve two purposes - they support data integrity upon the loss of a member and they also - the far less used case - reads for server-side code, when so configured.
The read-backup-data property is interesting, not often used, and not germane to your question.
Setting the backup count to '2' will do what you're describing. Think of it this way - for each primary partition on any member, there will be two backup copies - on two separate members. This will cause each member to have their normal count of primary partitions and double that, of backups.
In the same way, a backup count of '3' would make 3 backup copies - this is the most that you could do in a 4 member cluster. There'd be the 271 primary partitions and 3x that - 813 backup partitions.
It may be useful to note that, when choosing the backup count, you need to anticipate your worst-case assumption. With no backups, any member loss causes loss of data. (backup-count - 1) is the number of members that can exit without data loss. The max value for this is '6' - so you can configure a cluster for the simultaneous loss of 5 members. Beyond this, HA/DR stability is provided by persistence and/or WAN replication, an Hazelcast Enterprise feature.
Cheers
Tom
Vishal Patil
--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/72635ea9-270f-4fe9-8788-6558a6b26803n%40googlegroups.com.