Why does ApsaraDB for MongoDB trigger primary/secondary switchover?
ApsaraDB for MongoDB runs on a high availability (HA) architecture. When the HA system detects that a node is unavailable, it automatically triggers a primary/secondary switchover and notifies you by Short Message Service (SMS) or an internal message.
Notification example
[Alibaba Cloud] Dear \*\*\*\*: Your ApsaraDB for MongoDB instance dds-bp\*\*\*\* (name: \*\*\*\*) has an error. A switchover is triggered to ensure stable running of your instance. We recommend that you check whether your application is still connected to your instance and configure your application to automatically reconnect to your instance.
How it works
A replica set instance has three nodes by default. Each shard in a sharded cluster instance also has three nodes. Primary and secondary nodes handle application connections, while hidden nodes serve as standby targets for switchover. For more information, see Replica set instances or Sharded cluster instances.
Why a switchover was triggered
Two conditions can trigger a primary/secondary switchover:
Node unavailable: The node health monitoring system detects that a node is not responding and promotes a hidden node to primary.
Host offline: An exception occurs on the host running the primary node. The HA system switches to a healthy host to prevent extended downtime.
Troubleshoot the cause of an HA switchover
Excessive resource utilization, such as high CPU or memory utilization, can make a node unavailable and contribute to an HA switchover. To assess whether resource pressure contributed to a switchover, inspect the performance metrics for the period in which it occurred.
In the ApsaraDB for MongoDB console, open the target instance. In the left-side navigation pane, choose DAS Performance Trend.
Select the time range in which the switchover occurred. Review the following metrics and compare their changes with the switchover time:
CPU utilization and memory utilization: Sustained high utilization or a sudden spike can indicate that resource pressure affected node responsiveness.
Affected Documents and Scanned Indexes and Documents: Abnormal increases can indicate inefficient queries that consume instance resources.
Repl Opcounters and Oplog Retention Period: Abnormal values can help you assess replication activity and replication status.
If CPU or memory utilization is abnormal, choose Monitoring Information in the left-side navigation pane. Select the affected node and the corresponding time range to review its historical trend.
Correlate the abnormal metric period with the switchover time. A CPU utilization spike followed by an interruption in monitoring data is diagnostic evidence that resource pressure may have contributed to the instance switchover; assess it together with the other metrics before identifying the cause.
DAS Performance Trend is the upgraded name of the former Dukang-Telescope performance diagnostics feature.
When CPU utilization is abnormal, continue the investigation with Troubleshoot high CPU utilization on an ApsaraDB for MongoDB instance.
Impact of a switchover
The switchover causes a transient connection interruption of less than 30 seconds.
If your application connects directly to the primary node endpoint, read/write operations are affected during the switchover window.
What to do
For immediate reconnection issues: Configure your application to reconnect automatically after a disconnection. Most MongoDB drivers support automatic reconnection by default.
For production environments: Use a connection string URI to connect to the instance, so your application fails over to a healthy node automatically — keeping read/write operations available even when the primary switches. For more information, see Connect to a replica set instance or Connect to a sharded cluster instance.