Automatic and manual failover

Impact

• A primary/secondary switchover causes a service interruption that typically lasts for 15 seconds or less. You must ensure that your application has an automatic reconnection mechanism.

  If your application uses an older version of the Druid component for database connection management, it might fail to automatically reconnect after a disconnection. To avoid this issue, you can upgrade the Druid component to version 1.1.16 or later.

• If the primary instance has attached read-only instances, the read-only instances may experience a data delay of several minutes after the switchover. This is because RDS must rebuild the replication task and synchronize incremental data.

• A primary/secondary switchover does not change the instance endpoint, but the underlying IP address might change. We recommend that you use the endpoint to ensure that your application can continue to run as expected during the switchover.

• If the instance experiences a severe failure, the switchover may take longer than usual.

Perform a manual failover

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, click Service Availability.

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

4. Select a switchover time and click OK.

   Note

   Many operations, such as managing databases and accounts or changing the network type, are unavailable during a failover. To avoid service disruptions, we recommend selecting Within Specified Time Range.

Temporarily disable automatic failover

Automatic switchover is enabled by default. When the primary node fails, RDS automatically switches to the secondary node. You can temporarily disable automatic switchover for the following scenarios:

• To avoid any impact on system availability during major sales promotions.

• To prevent a switchover from introducing unexpected variables during critical application upgrades.

• During major events or stability assurance periods, you do not want a primary/standby switchover to affect 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, click Service Availability.

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

   Note

   If you do not see the Automatic Primary/Secondary Switchover button, confirm that your instance is of the High-availability Edition.

4. Select Temporarily Disable, set the End Time for Temporary Disablement, and then click OK.

   Note

   • When the End Time for Temporary Disablement is reached, automatic failover is automatically re-enabled.

   • By default, automatic failover is temporarily disabled for one day. You can set the end time up to seven days from the current date.

   After you complete the configuration, you can view the expiration time of the temporary disablement on the Service Availability page.

View primary/secondary switchover 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, click Service Availability.

3. In the Primary/Secondary Switchover Logs section, specify a time range to query the logs.

   

FAQ

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

  A: No. The data in the primary and standby instances is identical. After a failover, the former standby instance becomes the new primary instance. No further action is required.

• Q: It has been more than 10 minutes since a failover, but the instance status has not returned to Running. What could be the cause and how can I resolve it?

  A: During a high-availability failover in ApsaraDB RDS, long-lived application connections may not detect the status change. If a socket timeout is not configured, the application will wait indefinitely for a response from the database, which can take hundreds of seconds to disconnect. During this time, some database connections may not function correctly, leading to numerous SQL execution errors. To avoid these invalid connections and reduce downtime, we recommend that you configure connectTimeout and socketTimeout to prevent the application from waiting indefinitely during network errors.

  The ideal timeout values depend on your business workload and usage patterns. For online transaction processing (OLTP) workloads, a connectTimeout of 1 to 2 seconds and a socketTimeout of 60 to 90 seconds are recommended. These values are for reference only.

Related APIs