Performing a Primary/Standby Switchover or Failover in a RegionlessDB Cluster

Primary/Standby Switchovers

You can promote any standby instance to primary. After the switchover, the original primary instance will be added back to the cluster as a standby instance.

Before a switchover, all data on the primary instance will be synchronized to other standby instances, ensuring no data loss.

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.

Other Operations and Checks

The primary and standby instances are independent GaussDB(for MySQL) instances. During a primary/standby switchover or 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 primary/standby switchover or failover.

• Check the read/write addresses of your application.

  During a primary/standby switchover or 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 Monitoring and Alarms.