This is a prerelease version.

View latest

Cluster and Member States

Cluster states determine what cluster operations are available. By changing the state of a cluster, you can grant or restrict cluster operations such as repartitioning as well as change the behavior of those operations.

You may want to change a cluster’s state to do the following:

  • Add multiple new members to the cluster without triggering repartitioning after each member joins.

  • Perform maintenance on a cluster without triggering repartitioning.

Before you Begin

You should have a good understanding of data partitioning in Hazelcast clusters. See Data Partitioning.

Table 1. Glossary
Term Definition

migration

When a primary partition’s ownership is transferred from one member to another. Partition ownership is decided by the cluster’s master member and is followed by the physical movement of data over the network.

promotion

When the first replica of a partition becomes the primary. This operation requires no movement of data over the network.

replica sync

When the primary partition owner sends its data to replica owners for synchronization.

Cluster States

By default, all clusters are in an ACTIVE state. In this state, the cluster operates without restrictions.

All other cluster states restrict the operations on a cluster:

Table 2. Differences among cluster states
State New members Migrations Promotions Replica sync Use case

ACTIVE

Yes ✅

Yes ✅

Yes ✅

Yes ✅

Normal cluster operation

NO_MIGRATION

Yes ✅

No ❌

Yes ✅

Yes ✅

Adding multiple new members to the cluster without triggering repartitioning after each member joins.

FROZEN

No ❌

No ❌

No ❌

Yes ✅

Performing maintenance on a cluster without triggering repartitioning.

PASSIVE

No ❌

No ❌

No ❌

Yes ✅

Used internally during graceful cluster-wide shutdowns.

In this state, only read operations such as the map.get() and map.put() methods are allowed.

IN_TRANSITION

No ❌

No ❌

No ❌

No ❌

Used internally as a temporary state while the cluster state is still changing.

If an error occurs during a state change, Hazelcast does not try to change the cluster state again.

Repartitioning and backup operations are paused until the state is changed.

Frozen vs No Migration

The difference between the FROZEN state and the NO_MIGRATION state is in what happens when a member leaves the cluster.

In a NO_MIGRATION state, when a member leaves the cluster, the first replica of each partition owned by that member is promoted and partitions remain available.

In a FROZEN state, when a member leaves the cluster, the partitions owned by that member are unavailable until it rejoins or the cluster is put back into an ACTIVE state.

Member States

Individual members can be in the following states:

  • ACTIVE: Members are in this state when the state of a cluster is ACTIVE or FROZEN. See Cluster States on this page.

  • PASSIVE: Members transition to this state in the following circumstances:

    • During a graceful shutdown.

      When the graceful shutdown process is completed, the member’s state changes to SHUT_DOWN.

    • When the cluster’s state is manually changed to PASSIVE.

  • SHUT_DOWN: Members transition to this state when they are shut down. Members in this state reject all operations and invocations and cannot be restarted.

Changing a Cluster’s State

To change a cluster’s state, you can use one of the following:

You cannot change a cluster’s state to anything other than ACTIVE while members are repartitioning or backing up data.