Restart an instance, component, or node-ApsaraDB for MongoDB(MongoDB)-阿里云帮助中心

Limitations

You can restart a component only on sharded cluster instances.
You can restart a node only on instances that use Cloud Disks.

Usage notes

Restarting an instance stops and restarts its processes, which drops all active connections. Ensure that your application has an automatic reconnection mechanism.
Mongod and Mongos processes typically start within 30 seconds. However, if an instance has more than 10,000 collections, the Mongod startup time can extend to several minutes. You cannot connect to the node until startup is complete. To avoid prolonged restart times, we recommend that you keep the number of collections at 10,000 or fewer. For more information, see the official MongoDB documentation.
After a replica set instance restarts, node roles may change. We recommend that you use a high-availability (HA) connection string URI in your production environment. For more information, see Connect to a replica set instance.
When a sharded cluster instance restarts, connections are dropped as Mongos processes restart. We recommend that you use an HA connection string URI in your production environment and include the connection addresses of at least two Mongos nodes in the URI. For more information, see Connect to a sharded cluster instance.
After you restart a single node in a replica set instance, node roles may change. We recommend that you use an HA connection string URI in your production environment. For more information, see Connect to a replica set instance.
When you restart a single node in a shard of a sharded cluster instance, client connections are not dropped. However, write operations may fail. We recommend that you retry failed write operations.

Procedure

Restart instance

Log on to the ApsaraDB for MongoDB console.
In the navigation pane on the left, 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 of the target instance, click More and select Restart.
In the Restart Instance dialog box, click Confirm.

During the restart, the instance state changes to Restarting. When the state changes to Running, the instance restart is complete.

Restart component

Note

You can restart a component only on sharded cluster instances.

Go to the Sharded Cluster Instances page. At the top of the page, select a resource group and a region, and then click the ID of the target instance.
In the Mongos List or Shard List section, find the component that you want to restart. In the Actions column, click the icon and select Restart.
In the Restart Node dialog box, click Confirm.

During the restart, the instance state changes to Restarting. When the state changes to Running, the component restart is complete.

Restart node

Go to the Replica Set Instances or Sharded Cluster Instances page. At the top of the page, select a resource group and a region, and then click the ID of the target instance.
On the instance details page, in the navigation pane on the left, click Service Availability.
Find the node that you want to restart and click Restart Node in the Actions column.
In the Restart Node dialog box, click Confirm.

During the restart, the instance state changes to Restarting Node. When the state changes to Running, the node restart is complete.

FAQ

Q1: What happens when a replica set instance is restarted, and how does it affect the service?

The system restarts nodes in the following order: hidden node, secondary and read-only nodes, then performs a failover between the primary and secondary nodes, and finally restarts the former primary node. The impact on your service is as follows:
- Restarting a hidden node: No impact on your service.
- Restarting a secondary node: All connections to the secondary node are dropped and the client must reconnect. The primary node remains available and write operations are not affected. However, read operations configured with readPreference=Secondary are affected.
- Restarting a read-only node: All connections to the read-only node are dropped and the client must reconnect. The primary node remains available and write operations are not affected. However, read operations configured with readPreference=secondary&readPreferenceTags=role:readonly are affected. If the instance has multiple read-only nodes, read traffic is temporarily routed to another available read-only node during the restart.
- Failover: A transient disconnection of about 30 seconds occurs during the failover. If your application connects using the primary node address, the role change may affect read and write operations and cause write failures.
- Restarting the former primary node: All connections to this node (now a secondary node after the failover) are dropped and the client must reconnect. The impact is equivalent to restarting a secondary node.

Q2: What happens when a sharded cluster instance is restarted, and how does it affect the service?

The system restarts components in the following order: shard nodes, config server nodes, and then Mongos nodes. The impact on your service is as follows:
- Shard nodes: Multiple shard nodes are restarted in parallel. Client connections are not dropped, but write operations may fail. We recommend that you retry failed write operations.
- Config server nodes: No impact on your service.
- Mongos nodes: Multiple Mongos nodes are restarted in parallel. All connections to these nodes are dropped. Ensure that your application has an automatic reconnection mechanism.

Q3: Why does the instance keep showing "Restarting" after a restart?

If you set the switchover time to the maintenance window, the instance status remains "Restarting" until the switchover completes at the specified maintenance window time.