When Will a Primary/Standby Switchover Be Triggered for a Cluster or Replica Set?

Causes

The trigger for a switchover depends on the architectures: cluster or replica set.

• A cluster consists of three types of nodes: dds mongos, shard, and config. The shard and config nodes use a three-node replica-set architecture. If a primary node becomes faulty, it triggers a switchover.
• In a replica-set architecture there are also three nodes: primary, secondary, and hidden. The primary and secondary nodes provide IP addresses for external access. The primary node of a replica set instance is not fixed. If the configuration of the replica set instance changes, or if the primary node fails, or a switchover is triggered. A secondary node is promoted to primary, and the originally primary node is demoted to secondary.
• If the memory usage is too high, the instance is under heavy load and primary/standby switchover will occur.

For more information, see Cluster Architecture and Replica Set Architecture.

Impacts

• If a primary node fails, the system selects a standby node as the new primary within 30 seconds.
• If your applications are connected to a primary node that is demoted to standby due to a primary/standby switchover, the read and write operations on services will be affected.

Service Deployment Suggestion

Ensure that your application supports automatic reconnection, so the application can be automatically reconnected to the instance and avoid write errors in the event of a brief disconnects.

• It is recommended that you use URLs to connect the cluster and replica set instances. When a node is faulty, the primary/standby switchover does not affect service read and write operations. For details, see Connecting to a Cluster Instance and Connecting to a Replica Set Instance for Read and Write Separation and High Availability.
• If an instance is under heavy load, you can change the instance class. Take a cluster instance as an example. For details, see Changing a Cluster Instance Class.