PolarDB:Automatic failover and manual failover

Precautions

During a failover, whether automatic or manual, transient disconnections of approximately 20 to 30 seconds may occur if hot standby is not enabled for read-only nodes. Make sure that your applications can automatically reconnect to the cluster. When hot standby is enabled for read-only nodes, failover is completed within 5 to 10 seconds. For information about how to enable hot standby for read-only nodes, see Configure hot replica nodes.

Automatic failover

PolarDB clusters use an active-active high availability architecture. When a system failure occurs, automatic failover is performed between the writable primary node and read-only nodes, and the system automatically elects a new primary node.

Each node in a cluster has a failover priority, which determines the probability of each node being elected as the primary node during failover. When multiple nodes have the same priority, they have an equal probability of being elected as the primary node.

You can view and configure the failover priority of each node in the cluster on the Basic Information page in the Database Nodes section.

Manual failover

You can also manually perform a failover to promote a read-only node to the primary node. Manual failover is suitable for high availability drills or scenarios where you need to promote a specific node to the primary node.

1. Log on to the PolarDB console.

2. In the upper-left corner, select the region where the cluster is deployed.

3. Find the target cluster and click its ID.

4. On the Basic Information page in the Database Nodes section, click the icon in the upper-right corner to switch the view.

5. Click Fail Over.

6. In the dialog box that appears, select a new primary node and click OK to start the failover.

   Note

   • If the new primary node is a read-only node with hot standby disabled, transient disconnections of approximately 20 to 30 seconds may occur during the failover. Make sure that your applications can automatically reconnect to the cluster.

   • If the new primary node is a read-only node with hot standby enabled, the failover is completed within 5 to 10 seconds.

   • In some extreme scenarios, the duration of transient disconnections during failover may increase but does not exceed 3 minutes.

FAQ

• Q: After a failover, the cluster status does not return to Running after more than 10 minutes. What are the possible causes and how do I troubleshoot the issue?

• A: When a high availability failover is triggered, the application-side persistent connections may not detect the connection status change. If no socket timeout is configured, the application keeps waiting for the database to return results. Typically, the connection is not disconnected until several hundred seconds later. During this period, some database connections cannot work properly, and a large number of SQL execution errors occur.

  To avoid invalid connections, we recommend that you properly configure the connectTimeout and socketTimeout parameters of the MySQL driver to prevent indefinite waiting during network errors and reduce the fault duration.

  The values of these two parameters must be evaluated based on your business workload and usage patterns. For online transaction scenarios, the recommended values are as follows:

  • connectTimeout: We recommend that you set this parameter to 1 to 2 seconds.

  • socketTimeout: For internal network environments, we recommend that you set this parameter to 10 to 15 seconds. For public network environments, we recommend that you set this parameter to 60 to 90 seconds.

  Note

  The preceding recommended values are for reference only.

• Q: After a failover, why do the TPS/MPS metrics appear on the original read-only node instead of the original primary node?

• A: After a failover, the original read-only node is elected as the new primary node, and the original primary node is demoted to a read-only node. TPS/MPS metrics appear on the new primary node (the original read-only node), while the original primary node (now a read-only node) only shows QPS. This is normal behavior resulting from the role swap after failover.

  If traffic does not return to the read-only node after fault recovery, check the service node configuration of the cluster endpoint. If the read-only node was manually removed, add it back to restore traffic distribution.

Related operations