By default, each shard of an ApsaraDB for MongoDB sharded cluster instance contains three nodes. When a node fails, the high availability system of ApsaraDB for MongoDB automatically triggers a primary/secondary failover to ensure the overall availability. You can also manually trigger a primary/secondary failover for an ApsaraDB for MongoDB instance in scenarios such as routine disaster recovery drills.
Usage notes
ApsaraDB for MongoDB provides connection strings for you to connect to the primary node and a secondary node. The other secondary node is hidden as a backup to ensure high availability. After you log on to the ApsaraDB for MongoDB console or call the SwitchDBInstanceHA operation to trigger a primary/secondary failover for a shard of a sharded cluster instance, ApsaraDB for MongoDB switches the roles of the primary and secondary nodes.
- You can trigger a primary/secondary failover for replica set and sharded cluster instances, but not for standalone instances due to their single-node architecture.
- You can trigger a primary/secondary failover only for shards in the running state.
- Each time you trigger a primary/secondary failover for an instance, the instance may encounter a transient connection error of about 30 seconds. We recommend that you perform this operation during off-peak hours and make sure that your applications can automatically re-establish a connection.