ApsaraDB for MongoDB allows you to restart an instance, a component, or a node to resolve issues such as exhausted connections or poor performance.
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 starts its processes, dropping all active connections. Ensure that your application has an automatic reconnection mechanism.
The startup time for Mongod and Mongos processes is typically within 30 seconds. However, if an instance has a large number of collections (more than 10,000), the startup time for a Mongod process can extend to several minutes. You cannot connect to the corresponding node until the startup process is complete. To prevent long restart times from affecting your business, we recommend that you keep the number of collections at 10,000 or fewer. For more information, see the official MongoDB documentation.
After you restart a replica set instance, 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 you restart a sharded cluster instance, connections are dropped when the 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 to the database are not dropped. However, write operations may fail. We recommend that you retry write operations later.
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
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 is the backend process when a replica set instance is restarted, and how does it affect the service?
The system restarts the nodes in the following order: hidden node, then secondary and read-only nodes, then the system 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: This action has 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 is available and write operations are not affected. However, read operations that are configured with
readPreference=Secondaryare affected.Restarting a read-only node: All connections to the read-only node are dropped and the client must reconnect. The primary node is available and write operations are not affected. However, read operations that are configured with
readPreference=secondary&readPreferenceTags=role:readonlyare affected. If the instance has multiple read-only nodes, read traffic is temporarily routed to another available read-only node while one is restarting.Failover: During the failover, a transient disconnection of about 30 seconds occurs. If your application connects by using the address of the primary node, the role change may affect read and write operations, such as causing write failures.
Restarting the former primary node: All connections to the former primary node, which is 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 is the backend process when a sharded cluster instance is restarted, and how does it affect the service?
The system restarts the components in the following order: shard nodes, then config server nodes, and finally Mongos nodes. The impact on your service is as follows:
Shard nodes: The system restarts multiple shard nodes in parallel. During the restart, client connections are not dropped. However, write operations may fail. We recommend that you retry write operations later.
Config server nodes: This action has no impact on your service.
Mongos nodes: The system restarts multiple Mongos nodes in parallel. During the restart, all connections to the nodes are dropped. Ensure that your application has an automatic reconnection mechanism.