All Products
Search

This Product

    ApsaraDB for MongoDB:Read-only nodes

    Document Center

    ApsaraDB for MongoDB:Read-only nodes

    Last Updated:Apr 26, 2024

    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 to independent systems when primary and secondary nodes handle 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 read workloads and your business may be affected. In this case, you can create one or more read-only nodes based on your business requirements to handle a large number of database read requests. This increases application throughput.

    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 workloads on the primary and secondary nodes in business scenarios where a large number of read requests are received.

    • Read-only nodes have an independent connection string URI for an instance. Read-only nodes are suitable for direct connection to analysis program such as analysis servers. Read-only nodes do not interrupt the connections to existing primary and secondary nodes.

    • If your instance has two or more read-only nodes, you can use the read-only connection string URI to balance read requests received by the read-only nodes.

    Differences 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 the 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 encounter a 30-second transient connection. We recommend that you perform this operation during off-peak hours and make sure that your application can automatically re-establish a connection.

    • Read-only nodes have an independent connection string URI for an instance and are suitable for direct connection to independent systems. Read-only nodes do not interrupt the connections to existing primary and secondary nodes.

    • 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 process.

    If your instance has two or more read-only nodes, you can use the read-only connection string URI to balance read requests received by the read-only nodes. Read-only nodes are suitable for business scenarios where a large amount of data is read from an existing instance, 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 the 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 encounter a 30-second transient connection. We recommend that you perform this operation during off-peak hours and make sure that your application can automatically re-establish a connection.

    • If a secondary node fails, the secondary node cannot be elected as the primary node.

    • If the primary node fails, a secondary node can be elected as the new primary node to process read and write requests.

    Read and write requests can be separately handled by the primary and secondary nodes by using 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 greater than the number of write requests.

    Benefits

    • You can change the number of read-only nodes based on your requirements to reduce costs.

    • Read-only nodes have an independent connection string URI for an instance and are suitable for direct connection to independent systems. Read-only nodes do not interrupt the connections to existing primary and secondary nodes.

    • 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. The 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 the URI to connect to all read-only nodes in a replica set instance. To extend 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 handle only read requests and do not participate in election process 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 of a sharded cluster instance.

    • Data is asynchronously replicated from the primary node or secondary nodes to read-only nodes. In most cases, a millisecond-level latency may exist during data replication. If the primary node has high write workloads, second-level latency may exist.

    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 of a sharded cluster instance.