Package com.hazelcast.config

Class PartitionGroupConfig

java.lang.Object
com.hazelcast.config.PartitionGroupConfig
public class PartitionGroupConfig
extends Object
With PartitionGroupConfig, you can control how primary and backup partitions are mapped to physical Members.

Hazelcast will always place partitions on different partition groups so as to provide redundancy. There are three partition group schemes defined in PartitionGroupConfig.MemberGroupType: PER_MEMBER, HOST_AWARE CUSTOM, ZONE_AWARE, SPI.

In all cases a partition will never be created on the same group. If there are more partitions defined than there are partition groups, then only those partitions, up to the number of partition groups, will be created. For example, if you define 2 backups, then with the primary, that makes 3. If you have only two partition groups only two will be created.

PER_MEMBER Partition Groups

This is the default partition scheme and is used if no other scheme is defined. Each Member is in a group of its own.

Partitions (primaries and backups) will be distributed randomly but not on the same Member. 

 <partition-group enabled="true" group-type="PER_MEMBER"/>
This provides good redundancy when Members are on separate hosts but not if multiple instances are being run from the same host.

HOST_AWARE Partition Groups

In this scheme, a group corresponds to a host, based on its IP address. Partitions will not be written to any other members on the same host.

This scheme provides good redundancy when multiple instances are being run on the same host. 

 <partition-group enabled="true" group-type="HOST_AWARE"/>

CUSTOM Partition Groups

In this scheme, IP addresses, or IP address ranges, are allocated to groups. Partitions are not written to the same group. This is very useful for ensuring partitions are written to different racks or even availability zones.

For example, members in data center 1 have IP addresses in the range 10.10.1.* and for data center 2 they have the IP address range 10.10.2.*. You would achieve HA by configuring a CUSTOM partition group as follows: 

 <partition-group enabled="true" group-type="CUSTOM">
      <member-group>
          <interface>10.10.1.*</interface>
      </member-group>
      <member-group>
          <interface>10.10.2.*</interface>
      </member-group>
 </partition-group>
The interfaces can be configured with wildcards ('*') and also with address ranges e.g. '10-20'. Each member-group can have an unlimited number of interfaces.

You can define as many member-groups as you want. Hazelcast will always store backups in a different member-group to the primary partition. 

 <partition-group enabled="true" group-type="ZONE_AWARE"/>

Zone Aware Partition Groups

In this scheme, groups are allocated according to the metadata provided by Discovery SPI Partitions are not written to the same group. This is very useful for ensuring partitions are written to availability zones or different racks without providing the IP addresses to the config ahead. 
 <partition-group enabled="true" group-type="SPI"/>

SPI Aware Partition Groups

In this scheme, groups are allocated according to the implementation provided by Discovery SPI.

Overlapping Groups

Care should be taken when selecting overlapping groups, e.g. 
 <partition-group enabled="true" group-type="CUSTOM">
      <member-group>
          <interface>10.10.1.1</interface>
          <interface>10.10.1.2</interface>
      </member-group>
      <member-group>
          <interface>10.10.1.1</interface>
          <interface>10.10.1.3</interface>
      </member-group>
 </partition-group>
In this example there are 2 groups, but because interface 10.10.1.1 is shared between the 2 groups, this member may store store primary and backups.