ApsaraDB for MongoDB provides read-only nodes that have an independent connection string URL for an instance to offload read workloads from the primary and secondary nodes. Read-only nodes are applicable to direct connection scenarios where primary and secondary nodes are challenged by large amounts of read requests from applications.
In scenarios where large amounts of read requests are received and no write requests are available, primary and secondary nodes may be insufficient to handle the read pressure and your business may be affected. In this case, you can create one or more read-only nodes based on your needs to cope with massive database read requests to increase application throughput.
Structure of read-only nodes
Difference between read-only nodes and secondary nodes
|Secondary node||Secondary nodes can ensure high availability. When a secondary node of an instance fails, the system switches traffic to the hidden node of the instance to ensure that services are not interrupted. When the primary node of an instance fails, every secondary node of the instance has the chance to be promoted as the new primary node to process data write requests.||Primary and secondary nodes can be connected by using connection string URLs. This enables read/write splitting for instances and is applicable to scenarios that require more reads than writes. This way, performance is improved while the impacts of node failures on business are mitigated.|
|Read-only node||Read-only nodes synchronize data only from primary nodes. Read-only nodes cannot ensure high availability or be promoted as primary nodes. Read-only nodes in an instance have an independent connection string URL and can be connected independently of the primary and secondary nodes. Read-only nodes are suitable for direct connection from applications.||Read-only nodes are applicable to scenarios where large amounts of data need to be retrieved from existing instances. Similar scenarios include the use of business intelligence (BI) platforms and big data analytics.|
- The number of read-only nodes can be changed as your needs change to reduce costs.
- Read-only nodes in an instance have an independent connection string URL and can be connected independently of the primary and secondary nodes of replica set instances. Read-only nodes are applicable to direct connection from applications.
- Read-only nodes have the same specifications as primary and secondary nodes, and data in primary nodes can be automatically synchronized to read-only nodes without the need for maintenance.
- Read-only nodes are independent nodes that provide only read services. These nodes do not compete for resources with primary nodes. If you change the number of read-only nodes in an instance, the primary and secondary nodes in the instance are not affected and connections to the primary and secondary nodes are not closed.
- The same read-only connection string URL is provided for all read-only nodes in an instance. This allows you to increase the processing power of databases by adding read-only nodes without the need to change applications.
- Read-only nodes are supported only for subscription replica set instances, pay-as-you-go replica set instances, and subscription sharded cluster instances.
- Read-only nodes process only read requests and cannot be promoted as primary or secondary nodes.
- A maximum of five read-only nodes can be added to each replica set instance.
- A maximum of five read-only nodes can be added to each shard node of a sharded cluster instance.
- Data is asynchronously replicated with millisecond-level latency between a primary node and a read-only node.
- Only ApsaraDB for MongoDB instances that run MongoDB 3.4, 4.0, or 4.2 support read-only
Note ApsaraDB for MongoDB instances must be updated to the latest minor version. For more information about how to update the minor version of an instance, see Upgrade the minor version of an ApsaraDB for MongoDB instance.
The price of a read-only node is equivalent to that of a node in a replica set instance or that of a shard node in a sharded cluster instance.
For example, under the same specifications, the price of a three-node replica set instance is 3,000 and the price of a read-only node is 1,000.