This topic describes how to restart an ApsaraDB for MongoDB instance, a component, or a node. If databases in an ApsaraDB for MongoDB instance reach the maximum number of connections to the instance and experience degraded performance, you can attempt to manually restart the instance, a component in the instance, or a node in the instance.
Limits
You can perform component restart operations only on sharded cluster instances.
You can perform node restart operations only on instances that use cloud disks.
Usage notes
When an instance is restarted, processes that run on the instance are stopped and restarted, and all connections to the instance are closed. Make sure that your application can automatically reconnect to the instance.
In most cases, the mongod and mongos processes are started within 30 seconds. However, if the instance contains more than 10,000 collections, several minutes may be required for the mongod process to start. Before a mongod process is started, you cannot connect to the node on which the process is run. To prevent service interruptions caused by excessive restart time, we recommend that you use no more than 10,000 collections in your instance. For more information, see MongoDB documentation.
After a replica set instance is restarted, the role of a node in the instance may change. We recommend that you use a connection string URI in the production environment. For more information, see Connect to a replica set instance.
If a sharded cluster instance is restarted, connections to the instance are closed when the mongos process is restarted. We recommend that you use a connection string URI in the production environment and add the endpoints of at least two mongos nodes to the URI. For more information, see Connect to a sharded cluster instance.
After a node in a replica set instance is restarted, the role of the node in the instance may change. We recommend that you use a connection string URI in the production environment. For more information, see Connect to a replica set instance.
If a node in a shard component of a sharded cluster instance is restarted, connections between your client and the instance are not closed. However, data write operations may fail. We recommend that you retry write operations later.
Procedure
Restart an instance
Log on to the ApsaraDB for MongoDB console.
In the left-side navigation pane, click Replica Set Instances or Sharded Cluster Instances.
In the upper-left corner of the page, select the resource group and region to which the instance belongs.
Find the instance that you want to restart and click More in the Actions column. Then, select Restart.
In the Restart Instance message, click OK.
When the instance is being restarted, the instance is in the Restarting state. If the instance status changes to Running, the instance is restarted.
Restart a component
You can perform component restart operations only on sharded cluster instances.
Go to the Sharded Cluster Instances page. In the top navigation bar, select the region in which the instance resides. Then, find the instance and click the ID of the instance.
In the Mongos List or Shard List section of the instance details page, find the component that you want to restart and click the
icon in the Actions column. Then, select Restart. In the Restart Node message, click OK.
When the component is being restarted, the instance is in the Restarting state. If the instance status changes to Running, the component is restarted.
Restart a node
Go to the Replica Set Instances or Sharded Cluster Instances page. In the top navigation bar, select the region in which the instance resides and the resource group to which the instance belongs. Then, find the instance and click the ID of the instance.
In the left-side navigation pane of the instance details page, click Service Availability.
Find the node that you want to restart and click Restart Node in the Actions column.
In the Restart Node message, click OK.
When the node is being restarted, the instance is in the Restarting state. If the instance status changes to Running, the node is restarted.
FAQ
How does the system restart a replica set instance in the background? What are the impacts of the restart operation on my service?
The system restarts hidden nodes, secondary nodes and then read-only nodes. After that, the system proactively performs a primary/secondary switchover and finally restarts the original primary node. The restart operation has the following impacts on your service:
Restart hidden nodes: The restart operation that is performed on hidden nodes does not affect your service.
Restart secondary nodes: All connections to secondary nodes are closed, and you must re-establish a connection to the instance. In this case, the primary node of the instance is available and read/write operations are not affected. However, reads operations with the settings of readPreference=Secondary are affected.
Restart read-only nodes: All connections to read-only nodes are closed, and you must re-establish a connection to the instance. In this case, the primary node of the instance is available and read/write operations are not affected. However, reads operations with the settings of 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 of them is restarted.
Trigger primary/secondary switchover: During a primary/secondary switchover, a transient disconnection occurs, which lasts for about 30 seconds. If you use the endpoint of the primary node to connect to the instance, the node role changes. This may affect reads/writes operations. For example, you cannot write data.
Restart the original primary node: All connections to the original primary node are closed, and you must re-establish a connection to the instance. The impact is equivalent to restarting secondary nodes. Note that the original primary node becomes a secondary node after a primary/secondary switchover.
How does the system restart a sharded cluster instance in the background? What are the impacts of the restart operation on my service?
The system restarts shards, the ConfigServer component, and then mongos nodes. The restart operation has the following impacts on your service:
Restart shards: Multiple shards are restarted in parallel. Client connections are not closed during the restart, but the shards may fail to handle write operations. We recommend that you retry the write operations after the restart.
Restart the ConfigServer component: The restart operation that is performed on the ConfigServer component does not affect your service.
Mongos nodes: Multiple mongos nodes are restarted in parallel. During the restart, all connections to the mongos nodes are closed. Make sure that your application can automatically reconnect to the instance.