DocsICP FilingConsole
官方文档
首页

Read-only nodes

更新时间：
复制 MD 格式
产品详情
我的收藏

ApsaraDB for MongoDB read-only nodes have independent connection string URIs, allowing separate systems to connect directly and offload heavy read traffic from primary and secondary nodes.

In read-heavy scenarios, the primary and secondary nodes can become overloaded by read requests, which may impact your services. You can create one or more read-only nodes to handle high read volumes and increase application throughput.

Read-only node architecture

只读节点结构图

Read-only nodes have the following characteristics:

  • A read-only node synchronizes data from the primary or secondary node with the lowest latency by using the oplog. This reduces the read load on the primary and secondary nodes in read-heavy scenarios.

  • A read-only node has an independent connection string URI, suitable for direct connections from analytics applications such as an analysis server. Connecting to a read-only node does not interfere with existing connections to the primary and secondary nodes.

  • If you have two or more read-only nodes, you can use the ReadOnly ConnectionStringURI to implement load balancing for read requests.

Differences between read-only nodes and secondary nodes

Node

Similarities

Differences

Use cases

read-only node

  • When a system or application connects to a read-only node or secondary node by using its connection string URI, it has read-only access.

  • Both read-only nodes and secondary nodes provide high availability. If a node fails, the system automatically fails over to a healthy node. If automatic failover does not occur, you can perform a manual switchover. The connection string URI of the node remains unchanged.

    Note

    For more information about how to switch node roles, see Switch node roles.

    When a node role switch is triggered, a transient connection interruption of up to 30 seconds may occur. We recommend that you perform this operation during off-peak hours or ensure that your application has an automatic reconnection mechanism.

  • A read-only node cannot be elected as the primary node and does not participate in election votes.

  • A read-only node has an independent connection string URI, suitable for direct connections from separate systems and applications. Connecting to a read-only node does not interfere with existing connections to the primary and secondary nodes.

If you have two or more read-only nodes, you can use the ReadOnly ConnectionStringURI to implement load balancing for read requests. This is suitable for scenarios that require reading large amounts of data, such as business intelligence (BI) and big data analytics.

secondary node

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

  • Although a secondary node has an independent connection string URI, it may be elected as the new primary node if the current primary node fails. In this case, systems or applications connected to this node may gain write permissions.

You can use the connection string URI of the primary and secondary nodes to implement read/write splitting. This is suitable for concurrent scenarios with more reads than writes, allowing you to scale performance while protecting your services from node failures.

Benefits

  • You can change the number of read-only nodes at any time to manage costs.

  • Read-only nodes have independent connection string URIs, suitable for direct connections from separate systems and applications. They do not interfere with existing connections to primary and secondary nodes.

  • Read-only nodes share the same specifications as primary and secondary nodes. They automatically synchronize data from the primary or secondary node with the lowest latency, eliminating maintenance overhead.

  • Read-only nodes serve only read requests and do not consume the resources of the primary node. Adding or removing read-only nodes does not interfere with the workloads on the primary and secondary nodes or interrupt their connections.

  • ApsaraDB for MongoDB provides a unified address (ReadOnly ConnectionStringURI) for a replica set instance to connect to all of its read-only nodes. You can scale out read capacity by increasing the number of read-only nodes, without requiring any changes to your application.

    Note

    For more information about the ReadOnly ConnectionStringURI, see Connection description for a replica set instance.

Limitations

  • Read-only nodes are supported only for ApsaraDB for MongoDB replica set instances and sharded cluster instances.

  • Read-only nodes can process only read requests and do not participate in primary node elections.

  • You can add a maximum of five read-only nodes to a replica set instance.

  • You can add a maximum of five read-only nodes to each shard in a sharded cluster instance.

  • Data is asynchronously replicated from the primary or secondary node to read-only nodes. The replication latency is typically in the millisecond range but can increase to seconds when the primary node handles a heavy write load.

Billing

A read-only node is priced the same as a single node in its parent instance, whether the parent is a replica set instance or a shard in a sharded cluster instance.

Related documentation

Previous：Sharded cluster instancesNext：Specifications