Restart an ApsaraDB for MongoDB instance, component, or node to clear connection limits or resolve performance issues. All active connections drop during the restart, so make sure your application is configured to reconnect automatically before you proceed.
Limitations
You can restart components only on sharded cluster instances.
You can restart nodes only on instances that use cloud disks.
Understand the impact before restarting
Review the expected behavior for your restart scope before you proceed.
Instance restart behavior
| Instance type | What happens | Performance note |
|---|---|---|
| Replica set | All active connections drop. Node roles (primary/secondary) may change. Processes typically restart within 30 seconds. | If the instance has more than 10,000 collections, the mongod process can take several minutes to start. Keep collections at 10,000 or fewer. See the official MongoDB documentation for schema design guidance. |
| Sharded cluster | Shard nodes restart first (client connections are not dropped, but write operations may fail). Config Server nodes restart next (no service impact). Mongos nodes restart last, dropping all connections. Mongod and mongos processes typically restart within 30 seconds. | Same 10,000-collection limit applies to mongod processes in shard nodes. |
Component restart behavior (sharded cluster only)
| Component | Connection behavior | Write operations |
|---|---|---|
| Mongos | All connections to the Mongos node drop. Configure your application to reconnect automatically. | Connections are dropped; ensure your application reconnects automatically. |
| Shard | Client connections are not dropped. | May fail during restart; retry as needed. |
Node restart behavior
| Node type | Connection behavior | Write operations |
|---|---|---|
| Replica set node | All connections to that node drop. Node roles may change after restart. | Write operations on the primary are unaffected unless a primary/secondary failover occurs. |
| Shard node (sharded cluster) | Client connections are not dropped. | May fail during restart; retry as needed. |
Production recommendations
Use a high-availability (HA) connection string URI in production environments:
Replica set instances: The HA URI includes all node endpoints, so your application reconnects automatically after a role change. For details, see Connect to a replica set instance.
Sharded cluster instances: Add the endpoints of at least two Mongos nodes to the URI. For details, see Connect to a sharded cluster instance.
Restart an instance
Log on to the ApsaraDB for MongoDB console.
In the left navigation pane, click Replica Set Instances or Sharded Cluster Instances based on the instance type.
At the top of the page, select the resource group and region where the instance is located.
In the Actions column for the target instance, click More > Restart.
In the Restart Instance dialog box, click OK.
The instance status changes to Rebooting. When the status returns to Running, the restart is complete.
Restart a component
This operation applies to sharded cluster instances only.
Go to the Sharded Cluster Instances page. At the top of the page, select the resource group and region, then click the ID of the target instance.
In the Mongos List or Shard List area, find the component to restart and click Restart in the Actions column.
In the Restart Node dialog box, click OK.
The instance status changes to Rebooting. When the status returns to Running, the component restart is complete.
Restart a node
Go to the Replica Set Instances page or the Sharded Cluster Instances page. At the top of the page, select the resource group and region, then click the ID of the target instance.
In the left navigation pane of the instance details page, click Service Availability.
Find the node to restart and click Restart Node in the Actions column.
In the Restart Node dialog box, click OK.
The instance status changes to Restarting Node. When the status returns to Running, the node restart is complete.
FAQ
What is the restart sequence for a replica set instance, and what is affected at each stage?
The system restarts nodes in this order:
Hidden node — No impact on your service.
Secondary and read-only nodes — All connections to these nodes drop; your client must reconnect. Write operations are unaffected because the primary remains available. Read operations using
readPreference=Secondaryare temporarily affected. If the instance has multiple read-only nodes, read traffic shifts to another available read-only node while one is restarting. Read operations usingreadPreference=secondary&readPreferenceTags=role:readonlyare affected for that node.Primary/secondary failover — A transient disconnection of about 30 seconds occurs. If your application connects to the primary node address directly, write operations may fail during this window.
Former primary node (now secondary) — Same behavior as restarting a secondary node.
What is the restart sequence for a sharded cluster instance, and what is affected at each stage?
The system restarts components in this order:
Shard nodes — Restarted in parallel. Client connections are not dropped, but write operations may fail. Retry any failed write operations.
Config Server nodes — No impact on your service.
Mongos nodes — Restarted in parallel. All connections to these nodes drop. Configure your application to reconnect automatically.