ApsaraDB for MongoDB provides read-only nodes that have an independent connection string Uniform Resource Identifier (URI) for an instance to offload read workloads from the primary and secondary nodes. Read-only nodes are suitable for direct connection from independent systems where primary and secondary nodes are challenged by a large number of read requests.

In scenarios where a large number of read requests are received, 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 a large number of database read requests. This increases application throughput.

Architecture

Architecture
Read-only nodes have the following features:
  • Read-only nodes use oplogs to synchronize data from the primary or secondary node that has the lowest latency. Read-only nodes can be used to relieve read pressure on the primary and secondary nodes in business scenarios where a large number of read requests exist.
  • Read-only nodes can be connected independently of the primary and secondary nodes by using the read-only connection string URI and are suitable for direct connection from independent systems. For example, an analysis server can enjoy direct connection to read-only nodes if you add read-only nodes to your instance.
  • If your instance has two or more read-only nodes, read requests received by the read-only nodes can be balanced by using the read-only connection string URI.

Difference between read-only nodes and secondary nodes

Node Description Scenario
Read-only node
  • Read-only nodes provide high availability. If a read-only node fails, a hidden node is automatically elected as the new read-only node. If this operation is not automatically performed, you can manually perform this operation. After this process, the connection string URI used to connect to the read-only node remains unchanged.
    Note For more information, see Switch node roles.

    Each time node roles are switched, the instance may experience a transient connection of up to 30 seconds. We recommend that you perform this operation during off-peak hours or make sure that your application can automatically re-establish a connection.

  • Read-only nodes can be connected independently of the primary and secondary nodes by using the read-only connection string URI and are suitable for direct connection from independent systems.
  • Read-only nodes are not displayed in the secondary node list and cannot be elected as the primary node. Read-only nodes also do not participate in the primary node election.
If your instance has two or more read-only nodes, read requests received by the read-only nodes can be balanced by using the read-only connection string URI. Read-only nodes are suitable for business scenarios that process a large number of read requests, such as business intelligence (BI) and big data analytics.
Secondary node
  • Secondary nodes provide high availability. If a secondary node fails, a hidden node is automatically elected as the new secondary node. If this operation is not automatically performed, you can manually perform this operation. After this process, the connection string URI used to connect to the secondary node remains unchanged.
    Note For more information, see Switch node roles.

    Each time node roles are switched, the instance may experience a transient connection of up to 30 seconds. We recommend that you perform this operation during off-peak hours or make sure that your application can automatically re-establish a connection.

  • When a secondary node fails, the secondary node cannot be elected as the primary node.
  • When the primary node fails, every secondary node has the chance to be elected as the new primary node to process read and write requests.
Read and write requests can be separately processed by the primary and secondary nodes with the use of different connection string URIs. This improves instance performance and prevents node failures from affecting business. Secondary nodes are suitable for scenarios where the number of read requests is much greater than the number of write requests.

Benefits

  • The number of read-only nodes can be changed as your needs change to reduce costs.
  • Read-only nodes can be connected independently of the primary and secondary nodes by using the read-only connection string URI and are suitable for direct connection from independent systems.
  • Read-only, primary, and secondary nodes have the same specifications. This allows read-only nodes to synchronize data from the primary or secondary node that has the lowest latency and eliminates maintenance needs.
  • 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.
  • ApsaraDB for MongoDB provides a unified read-only connection string URI for replica set instances. You can use this URI to connect to all read-only nodes in a replica set instance. To extend the database capabilities, you can add more read-only nodes without changing your application code.
    Note For more information, see Connect to a replica set instance.

Limits

  • Read-only nodes are available only for replica set and sharded cluster instances.
  • Read-only nodes process only read requests and do not participate in election for the primary node or the 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 from the primary node or secondary nodes to read-only nodes. In most cases, latency of milliseconds can be observed during the data replication. However, latency of seconds can be observed if the primary node is challenged by high write pressure.

Pricing

The price of a read-only node is equivalent to that of a node in a replica set instance or that of a node in a shard node of a sharded cluster instance.