Read-only nodes give your ApsaraDB for MongoDB instance a dedicated read tier with its own connection string URI (Uniform Resource Identifier). When primary and secondary nodes are saturated with read requests, add read-only nodes to absorb the excess load without touching your existing connections.
How it works
Read-only nodes sync data from whichever primary or secondary node has the lowest latency, using MongoDB's oplog mechanism. Replication is asynchronous: under normal conditions latency is millisecond-level, but it can rise to second-level when the primary node is under heavy write workloads.
Each read-only node runs at the same specifications as the primary and secondary nodes, so there is no resource contention and no performance penalty on the replica set.
Node roles at a glance:
Primary node — handles read and write requests.
Secondary node — handles read requests; can be elected primary if the primary node fails.
Read-only node — handles read requests only; never participates in primary elections and is not displayed in the alternative primary node list.
Read-only nodes vs. secondary nodes
| Read-only node | Secondary node | |
|---|---|---|
| Reads | Yes | Yes |
| Writes | No | No (unless elected primary) |
| Election participation | Never — not displayed in the alternative primary node list and cannot be elected as primary | Yes — can become primary on failover |
| Independent connection string URI | Yes — dedicated read-only URI | Yes — but may gain write access if elected primary |
| Load balancing across nodes | Yes — with 2 or more read-only nodes, the read-only URI distributes requests across all of them | No |
| High availability | If a node fails, the system automatically switches your business to a healthy node. If the automatic switchover does not occur, you can manually perform the switchover. Endpoints remain unchanged during this process. | If the primary node fails, a secondary node can be elected as the new primary node. |
| Best for | BI, big data analytics, workloads that must be fully isolated from the replica set | Separating read and write traffic while maintaining standard high availability |
Each time node roles are switched, the instance may experience a 30-second transient connection interruption. Perform role switches during off-peak hours and make sure your application reconnects automatically. For details, see Switch node roles.
Use cases
Business intelligence (BI) and analytics — connect analysis servers directly to read-only nodes so reporting queries never compete with production traffic.
High read-to-write ratio workloads — scale out read capacity independently by adding nodes without changing application code that connects to the primary or secondary nodes.
Limitations
Read-only nodes are available only for replica set instances and sharded cluster instances.
Each replica set instance supports a maximum of five read-only nodes.
Each shard in a sharded cluster instance supports a maximum of five read-only nodes.
Read-only nodes handle read requests only and do not participate in primary elections.
Replication is asynchronous. Millisecond-level latency is typical; second-level latency may occur when the primary node has high write workloads.
Billing
A read-only node is billed at the same rate as a node in a replica set instance or a shard node in a sharded cluster instance.
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 and are suitable for direct connection to independent systems. They do not interrupt connections to existing primary and secondary nodes.
Read-only, primary, and secondary nodes share the same specifications. This enables read-only nodes to synchronize data from the primary or secondary node with the lowest latency and eliminates maintenance overhead.
Read-only nodes are independent nodes that provide only read services and 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 are not affected and connections to them 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.
What's next
Add read-only nodes when creating an instance:
Create a replica set instance — set the Read-only Nodes parameter during creation.
Create a sharded cluster instance — set the Shard Read-only Nodes parameter during creation.
Change the number of read-only nodes on an existing instance:
Change the configurations of a replica set instance
Pay-as-you-go instance: click Change Configurations.
Subscription instance: click Upgrade or Downgrade.
Change the configurations of one or more shards
Pay-as-you-go instance: click Change Configurations for a single shard, or Batch Change Configurations for multiple shards.
Subscription instance: click Upgrade or Downgrade for a single shard, or Batch Upgrade / Batch Downgrade for multiple shards.
Connect to your instance: