How Do I Check the Causes of an Active/Standby Switchover?
Question
How do I check the causes of an active/standby switchover?
Answer
- Heartbeat loss (0).
- Gateway disconnection (6).
- Service network interruption (5) (abnormal setting of the floating IP address).
- Active/Standby switchover (2).
The alarm generated during the active/standby switchover also contains the causes for switching. You can view the records on the web page, as shown in Figure 9-1.
When the gateway and service network are disconnected, to prevent the alarm sending failure caused by network faults, a scheduled resending function is provided.
Table 9-1 lists the possible causes of a active/standby switchover.
Switchover Cause |
Description |
---|---|
"Swap to Active. According to the roles on both sides" "Swap to Standby. According to the roles on both sides" |
If one side is in active mode and the other one in unknown mode, the unknown side becomes the standby node. |
"Swap to Active. Peer resource (containers) abnormal" "Swap to Standby. Local resource (containers) abnormal" "Swap to Active. Local has more resource" "Swap to Standby. Local has less resource" |
If a key container on the active node is abnormal or more resources are configured on the standby node, an active/standby switchover is triggered. |
"Swap to Active. Local activation time is longer" "Swap to Standby. Local activation time is shorter" |
The active time determines the active/standby status. Generally, this problem occurs when there are two active devices. If the resource status cannot be used to determine the active/standby status, check the active time of both devices. The device with a longer active time is the active node and the other with a shorter active time is the standby end. |
"Swap to Active. Local ip is smaller" "Swap to Standby. Local ip is bigger" |
The heartbeat IP addresses determine the active/standby status. Generally, this situation occurs when there are two active/standby nodes or during initialization. If the active and standby roles, resource status, and active time cannot determine the active/standby status, the first heartbeat IP address of the two nodes is utilized. The node with a smaller heartbeat IP address is the active node, and the node with a larger heartbeat IP address is the standby node. |
"Swap to Active. Peer is initializing" "Swap to Standby. Local is initializing" |
The initialization state determines the active/standby status. Generally, this situation occurs during the initialization process. When one device is started and running properly and the other device is being initialized, the device that is running properly is the active node and the other is the standby node. |
"Swap to Active. Cmd force swap" "Swap to Standby. Cmd force swap" |
You can run a command to forcibly trigger a switchover on the active node only when both the active and standby devices in the HA system are running properly. |
"Swap to Active. Mailbox force swap" "Swap to Standby. Mailbox force swap" |
A switchover can be forced when a container invokes the switchover interface through a container mailbox. The forced swap can be triggered on the active node only when both the active and standby nodes are running properly. |
"Swap to Active. Peer netdown (set active float ip failed)" "Swap to Standby. Local netdown (set active float ip failed)" "Swap to Active. Peer netdown (peer eth link status is down)" "Swap to Standby. Local netdown (local eth link status is down)" |
When the active node fails to set the active floating IP address, or the network port for which the active floating IP address is configured is disconnected, an active/standby switchover is triggered to enable the standby node to attempt to set the active floating IP address. |
"Swap to Active. Local database has more log" "Swap to Standby. Local database has less log" "Swap to Active. Local database is normal while peer is recovering" "Swap to Standby. Local database is recovering while peer is normal" "Swap to Active. According to the database status on both sides" "Swap to Standby. According to the database status on both sides" |
When the GaussDB database is configured, the active/standby status can be determined by the database statuses of both sides. Currently it is not supported by the HA system. |
"Swap to Active. Peer breakdown" |
When the peer active node breaks down, the local standby node can ping the arbitration IP address but cannot ping the floating IP address of the active node. Therefore, the local node considers that the active node does not exist, and the local network is normal. As a result, the local node can switch to the active node. |