Performing a Failover in a RegionlessDB Cluster

Failovers

If the primary instance in a RegionlessDB cluster fails and cannot be restored, usually due to a regional outage, a failover is triggered to promote the standby instance with the latest data from all available standby instances to the primary instance.

A failover may result in some data loss, depending on the replication latency between the primary and standby instances during the failover.

Generally, a failover can be complete within several minutes. However, after a failover is performed, the original primary instance needs to be rebuilt as a standby instance before being added back to the entire cluster. The rebuilding process may take dozens of minutes to several hours, depending on the data volume and network conditions between regions.

If a failover is required, submit a service ticket.

Other Operations and Checks

The primary and standby instances are independent TaurusDB instances. During a failover, the configurations between the primary and standby instances are not exchanged. To prevent performance and compatibility issues caused by different configuration parameters, you are advised to check for any differences in configuration items between the primary and standby instances after a failover.

• Check the read/write addresses of your application.

  During a failover, the read/write addresses of instances are not exchanged. You need to check whether the read/write address of your application is as expected.

  During a failover, you can configure an application to use the read/write address of the new primary instance. After the faulty instance is rebuilt, reconfigure the read/write address of the application.

• Check the write forwarding configurations of standby instances. For details, see Step 3: Enable Write Forwarding.
• Check the configurations of a parameter template. For details, see Modifying Parameters of a DB Instance.
• Configure monitoring alarms. For details, see Metrics and Alarms.