A HA instance can switch into different HA states. The current state is displayed in the "Usage" section of the HA Controller Swiftlet:
A state change is also written to System.out and the info log file of the HA instance.
The following table lists all possible HA states:
| State | Description |
|---|---|
| UNKNOWN | State is unknown. This is the case on the very first startup. The HA instance will now wait for negotiation. |
| INITIALIZE | A network connection has been established and the replication channel is being initialized. |
| NEGOTIATE | A temporary master is elected that drives the negotation about which HA instance will become ACTIVE and which STANDBY. |
| ACTIVE-SYNC-PREPARE | ACTIVE instance prepares synchonization with STANDBY. In particular it freezes its thread pools. |
| ACTIVE-SYNC | ACTIVE instance creates a snapshot and transfers it to the STANDBY. |
| ACTIVE | Synchronization completed, thread pools unfreezed, active replication in progress. |
| STANDBY-SYNC-PREPARE | STANDBY instance prepares synchronization with ACTIVE. |
| STANDBY-SYNC | STANDBY instance receives snapshot from ACTIVE instance. |
| STANDBY | Synchronization completed, STANDBY receives replication stream. |
| STANDALONE | The other instance is not connected. HA instance works standalone. |
The following graph shows the HA state changes during connect and synchronization until the HA instances are reaching ACTIVE and STANDBY state:
The following graph shows the HA state changes after the ACTIVE HA instance fails:
A failover is a transparent transition from the ACTIVE to the STANDBY HA instance when the ACTIVE HA instance fails.
Before a failover, there is an ACTIVE HA instance with JMS client connections (and may be routing connections) that is connected by a replication channel to the STANDBY HA instance:
Now the ACTIVE HA instance fails (e.g. power fail). The STANDBY detects it because it either gets an IOException on the replication channel or it missed the maximum number of heart beat messages. The STANDBY switches to HA state STANDALONE and JMS clients transparently reconnect to this HA instance:
If the previous ACTIVE HA instance comes back up, a replication channel is established between the 2 instances. The STANDALONE instance will become ACTIVE and the other instance will be STANDBY:
If the left HA instance should always be the ACTIVE HA instance (e.g. it is the faster machine), it has to be flagged as the "Preferred Active" instance. In that case, the right HA instance would be automatically rebooted which would lead to a failover to the left one, which would first become STANDALONE and then ACTIVE.