Versions Compared

Old Version 3

changes.mady.by.user Leeza Gavronsky

Saved on

compared with

New Version Current

changes.mady.by.user Leeza Gavronsky

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

...

Each node at start receives information about available nodes in the cluster and decides whether or not it should be elected a leader in that moment. This decision is based on the presence or absence of a quorum (see Hazelcast configuration). It is considered that the cluster has a quorum (and the leader can be chosen) if

...

If the quorum size is not specified, it is considered that even one node already composes a quorum.

Info

Current implementation only automatically chooses a leader in the cluster when the cluster did not have a leader before.

The first time leader selection algorithm is:

  1. If the new node has decided that it is necessary to choose a leader, it sends the LEADER_EVENT event to the cluster and offers a new leader.

  2. Once the proposed new leader gets the LEADER_EVENT event with its ID, it notifies the application about its new status by calling LocalNodeLeaderListener.onGranted() and sends the LEADER_STARTED_EVENT event with its ID back to the cluster.

  3. When the rest of the cluster nodes receive the LEADER_STARTED_EVENT event , they set their state to BACKUP (mark themselves as backup), and notify their applications about the new status by calling LocalNodeBackupListener.onBackup().

Info

You can check the presence of the leader in the cluster by using HazelcastClusterManager.hasLeader() method.

Appointment of a new leader

...

  1. The node that calls the HazelcastClusterManager.electLeader() method sendsthe sends the cluster LEADER_EVENT event a new leader ID.

  2. When the backup node receives the LEADER EVENT event, it calls the LocalNodeBackupListener.offBackup() method.

  3. The node that was elected as the new leader launches a timer and waits for the old leader to be finishedfinish. This mechanism was introduced to minimize the possibility of two leaders in the cluster working simultaneously. The old leader needs some time to complete its processes. A timer is used to protect the cluster from endless waiting when the old leader becomes inaccessible or crashes while leaders are being switched.

  4. The old leader receives the LEADER_EVENT event and notifies its application about the status change by calling LocalNodeLeaderListener.onRevoked(). After this call is completed successfully, it sends a LEADER_STOPPED_EVENT event to the cluster.

  5. When the new leader node receives a LEADER_STOPPED_EVENT event, (or if it doesn’t receive this event during timeoutLeaderShutdown period), it notifies the application about the new status by calling LocalNodeLeaderListener.onGranted() and sends to the cluster LEADER_STARTED_EVENT event with its ID.

  6. When the rest of the cluster nodes receive the LEADER_STARTED_EVENT event, they change their state to BACKUP (mark themselves as backup) and notify their applications about the new status by calling LocalNodeBackupListener.onBackup().

...

Since version 1.4.0, by default, the new leader can be automatically elected when the existing leader is gone. Configuration options are described here.