ApsaraDB RDS:Primary/standby failover

Impacts

• A primary/standby failover causes a brief service interruption of up to 15 seconds. Ensure that your application has an automatic reconnection mechanism.

  If your application uses an older version of the Druid component for database connection management, your application's connections may fail to reconnect automatically after a disconnection. We recommend that you upgrade Druid to version 1.1.16 or later to prevent this issue.

• If your instance has attached read-only instances, read-only instances may experience replication delays of several minutes after a failover. This is because the replication link needs to be rebuilt and incremental data needs to be synchronized.

• A primary/standby failover does not change the instance endpoint, but the underlying IP address might change. As long as you use the instance endpoint, a failover does not affect your application.

• If an instance fails, the failover process may take longer.

Manually switch primary and standby nodes

1. Go to the Instances page. In the top navigation bar, select the region in which the RDS instance resides. Then, find the RDS instance and click the ID of the instance.

2. In the navigation pane on the left, choose Service Availability.

3. In the Availability Information section, click Switch Primary/Secondary Instance.

4. Select a switchover time and click Ok.

   Important

   During a primary/standby failover, you cannot perform many operations, such as managing databases and accounts or switching network types. We recommend that you select Switch Within the Specified Time.

   For Cluster Edition instances, you can also perform a primary/standby failover from the instance topology diagram on the Basic Information page.

Temporarily disable automatic primary/standby failover

Auto-failover is On by default. When the primary node fails, the system automatically triggers a failover to the standby node. You can temporarily disable automatic primary/standby failover in the following scenarios:

• During major promotions, to prevent a failover from affecting system availability.

• During critical application upgrades, to avoid introducing failover as a variable.

• During major events or periods that require maximum stability, to prevent a failover from affecting system stability.

1. Go to the Instances page. In the top navigation bar, select the region in which the RDS instance resides. Then, find the RDS instance and click the ID of the instance.

2. In the navigation pane on the left, choose Service Availability.

3. In the Availability Information section, click Automatic Primary/Secondary Switchover.

   Note

   If you cannot see the Automatic Primary/Secondary Switchover button, confirm that your instance meets the prerequisites in this topic.

4. Select Temporarily Disable, set the Temporary Disabling End Time, and then click Ok.

   Note

   • When the Temporary Disabling End Time is reached, automatic primary/standby failover automatically resumes.

   • By default, automatic failover is temporarily disabled for one day. You can set the end time to a maximum of 23:59:59 seven days from the current date.

After you complete the settings, you can view the end time of the temporary suspension on the Service Availability page.

View primary/standby failover logs

1. Go to the Instances page. In the top navigation bar, select the region in which the RDS instance resides. Then, find the RDS instance and click the ID of the instance.

2. In the navigation pane on the left, choose Service Availability.

3. In the Primary/Secondary Switching Logs section, adjust the query time range to view the logs.

   The log table includes columns such as Switchover Event ID, Switchover Start Time, Switchover End Time, and Reason. The log table records details for each primary/standby failover. For example, a manual failover is logged with the reason Manual Operation (Instance HA Switchover).

FAQ

• Q: Can I access the standby node?

  A: You can access the standby node only for Cluster Edition instances. For instances of other editions, the standby node is not accessible.

• Q: After a failover, do I need to manually switch back to the original primary node?

  A: No. The data on the primary and standby nodes is identical. After a failover, the former standby node becomes the new primary node. No additional action is required.

• Q: What should I do if the instance status does not return to Running for more than ten minutes after a failover?

  A: When an exception triggers a high-availability failover in RDS, long-lived application connections may not detect the change in connection status. If a socket timeout is not set, the application waits indefinitely for a response from the database, which can take several hundred seconds before disconnecting. During this time, some database connections may not work, and a large number of SQL execution errors may occur. To avoid these invalid connections, we recommend that you configure the connectTimeout and socketTimeout parameters. This prevents the application from waiting indefinitely during a network error and shortens the recovery time.

  Evaluate the timeout values based on your business workload and usage patterns. For online transaction processing (OLTP) workloads, we recommend setting connectTimeout to 1–2 seconds and socketTimeout to 60–90 seconds. These values are for reference only.

Related APIs