Switch between a disaster recovery instance and a primary instance
If all nodes of the primary instance in a disaster recovery instance group become unavailable — for example, when both the primary and secondary nodes are down — you can switch the disaster recovery instance to the primary role to quickly restore read-write access. After the switchover, the previously read-only disaster recovery instance becomes the read-write primary instance, and the original primary instance becomes the read-only disaster recovery instance.
This operation suits planned scenarios such as disaster recovery drills, geo-disaster recovery switchovers, and rapid data migration.
If the primary instance's region is unavailable, or if data synchronization latency prevents a standard switchover, promote the disaster recovery instance to the primary instance instead. Promotion bypasses full data sync and accepts potential data loss, while a switchover enforces data consistency and fails safely if sync cannot complete within 5 minutes.
Prerequisites
Before you begin, make sure that the disaster recovery instance group is in the Running state. If the group is in a transitional state (such as Switching Instance), wait for it to return to Running before proceeding.
Usage notes
Transient connection: The switchover triggers a transient connection lasting approximately 10 seconds. Perform the switchover during off-peak hours and make sure your application has an automatic reconnection mechanism.
Data consistency enforcement: Data consistency between the primary and disaster recovery instances is strictly checked before the switchover completes. Data loss does not typically occur during a planned switchover. However, if data synchronization latency exists and a full sync does not complete within 5 minutes of initiating the switchover, the operation fails. This mechanism protects data consistency.
Endpoint and network changes required: After the switchover, connections to the original primary instance's endpoint become read-only. Update your application to use the new primary instance's endpoint, and reconfigure network access — for example, configure an IP whitelist and verify network connectivity.
Switch the roles
Go to the Global Database page.
On the Global Distributed Cache page, click the instance ID of the target instance group.
In the List of RDS instances section at the bottom of the page, find the instance with the secondary role, and click Switch to Primary Instance in the Actions column.
Review the effects of the role switch, and then click Switch. The instance group status changes to Switching Instance. The process takes less than 10 minutes.
Result
After the switchover completes, the primary and secondary roles are swapped and the data synchronization direction is inverted.
| Item | Before switch | After switch |
|---|---|---|
| Primary/Secondary role | Primary instance: read-write. Disaster recovery instance: read-only. In the instance list, you can confirm the cross-region disaster recovery deployment status: the primary instance is located in China (Chengdu), and the secondary instance is located in China (Hohhot). Both instances are in the Running state. | The disaster recovery instance becomes the primary instance. The original primary instance becomes the disaster recovery instance. After the switchover, the instance in China (Hohhot) takes the primary role, and the instance in China (Chengdu) takes the secondary role. |
| Data synchronization direction | From the primary instance to the disaster recovery instance. On the DTS Instance List page, you can view the created data synchronization instance. The Region column shows the source as China (Chengdu) and the destination as China (Hohhot). The Running Status is Running. | From the disaster recovery instance to the primary instance. On the DTS Instance List page, locate the target instance and confirm that the Region column shows the source as China (Hohhot) and the destination as China (Chengdu), and that the Running Status is Running. |
What's next
After the switchover, complete the following tasks to restore full application access:
Update your application's connection string to point to the new primary instance's endpoint.
Configure an IP whitelist for the new primary instance to allow connections from your application servers.
Verify network connectivity between your application and the new primary instance.