You can restart instances, components, and nodes in ApsaraDB for MongoDB. If a database reaches its connection limit or experiences performance issues, you can manually restart an instance, a component, or a node to resolve the problem.
Limits
You can restart components only on sharded cluster instances.
You can restart nodes only on instances that use cloud disks.
Notes
When you restart an instance, its processes are stopped and then restarted. All active connections are disconnected. Ensure that your application is configured to automatically reconnect.
The mongod and mongos processes typically start within 30 seconds. However, if the instance has more than 10,000 collections, the mongod process can take several minutes to start. You cannot connect to the node until the process is complete. To prevent long restart times from affecting your service, limit the number of collections to 10,000 or fewer. For more information, see the official MongoDB documentation.
After a replica set instance restarts, the roles of its nodes may change. In a production environment, use a high-availability (HA) connection string URI. For more information, see Connect to a replica set instance.
When you restart a sharded cluster instance, connections are dropped during the Mongos process restart. In a production environment, use an HA connection string URI and add the endpoints of at least two Mongos nodes to the URI. For more information, see Connect to a sharded cluster instance.
After you restart a single node in a replica set instance, the roles of nodes may change. In a production environment, use an HA connection string URI. For more information, see Connect to a replica set instance.
When you restart a single node in a shard component of a sharded cluster instance, the client connection to the database is not disconnected. However, write operations may fail. You may need to retry the write operations.
Procedure
Restart an instance
Log on to the ApsaraDB for MongoDB console.
In the navigation pane on the left, click Replica Set Instances or Sharded Cluster Instances, depending on the instance type.
In the upper-left corner of the page, select the resource group and region where the instance is located.
In the Actions column for the target instance, click More and select Restart.
In the Restart Instance dialog box, click the Confirm button.
During the restart, the instance status is Restarting. When the status changes to Running, the instance has successfully restarted.
Restart a component
You can restart components only on sharded cluster instances.
Go to the Sharded Cluster Instances page. At the top of the page, select the resource group and region, and then click the ID of the target instance.
In the Mongos List or Shard List area, find the component to restart, click the
icon in the Actions column, and select Restart.In the Restart Node dialog box, click OK.
During the restart, the instance status is Restarting. When the status changes to Running, the component has restarted.
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, and then click the ID of the target instance.
In the navigation pane on the left of the instance details page, click Service Availability.
Find the node that you want to restart, and in the Actions column, click Restart Node.
In the Restart Node dialog box, click OK.
During a node restart, the instance status is Restarting Node. The node has restarted successfully when the status changes to Running.
FAQ
Q1: What happens when a replica set instance is restarted, and how does it affect services?
A: The system first restarts the hidden node, then the secondary and read-only nodes. Next, it performs a primary/secondary failover and finally restarts the original primary node. The impact on your services is as follows:
Restarting the hidden node: No impact on your service.
Restarting secondary nodes: All connections to the secondary nodes are dropped. Your client must reconnect. The primary node remains available, so write operations are not affected. However, read operations with `readPreference=Secondary` are affected.
Restarting read-only nodes: All connections to the read-only nodes are dropped. Your client must reconnect. The primary node remains available, so write operations are not affected. However, read operations with `readPreference=secondary&readPreferenceTags=role:readonly` are affected. If the instance has multiple read-only nodes, read traffic is temporarily transferred to another available read-only node when one is restarted.
Primary/secondary failover: A transient disconnection occurs for about 30 seconds during the failover. If your application connects using the primary node's address, the change in node role may affect read and write operations. For example, data writes may fail.
Restarting the former primary node: All connections to the former primary node, which is now a secondary node, are dropped. Your client must reconnect. The impact is the same as restarting a secondary node.
Q2: What happens when a sharded cluster instance is restarted, and how does it affect services?
A: The system restarts the shard nodes, then the Configserver nodes, and finally the Mongos nodes. The impact on your services is as follows:
Shard nodes: Multiple shard nodes are restarted in parallel. Client connections are not dropped during the restart, but write operations may fail. You may need to retry the write operations.
Configserver nodes: No impact on your service.
Mongos nodes: Multiple Mongos nodes are restarted in parallel. During the restart, all connections to these nodes are dropped. Ensure that your application is configured to automatically reconnect.