Read Replica

To improve the read capability of the primary node, DDS provides read replicas that can be accessed independently, which is good for handling read-intensive workloads and reducing memory pressure on the primary node. You can also create one or more read replicas to process a large number of read requests and improve throughput.

Differences Between Read Replica and Secondary Node

Node	Description	Application Scenario
Secondary nodes	The secondary node ensures high availability. If a primary node fails, the system automatically switches traffic to the secondary node. If the primary node is faulty, each secondary node may be elected as a new primary node to execute data write requests.	DDS provides an HA connection address to connect to both the primary and secondary nodes and separate read and write operations. In this way, a DDS instance can handle heavy read workloads with ease. In addition, the impact of node faults on services is wakened while the performance is improved.
Read replicas in a replica set instance	A read replica in a replica set instance synchronizes data only from the primary node. It does not ensure high availability and will not be elected as the primary node. A read replica can be accessed through an independent connection. It will not interfere with connections between your applications and the primary and secondary nodes of a replica set instance.	Read replicas are useful when applications need to read large amounts of data from existing instances.
Read replicas in a cluster instance	Read replicas in a cluster instance ensure high availability. If a read replica fails, the system automatically switches workloads to another available read replica or secondary node. A read replica in a cluster instance can be accessed through an independent connection. It will not interfere with connections between your applications and the primary and secondary nodes of a cluster instance. All read replicas can be connected using a unified address, so you can expand the read capability of your applications by adding read replicas without modifying the connection address. A read replica in a cluster instance will not be elected as the primary node.	Read replicas are for scenarios where applications need to read large amounts of data from existing instances, read request load balancing is required, and read replica HA is required.

Node

Description

Application Scenario

Secondary nodes

The secondary node ensures high availability. If a primary node fails, the system automatically switches traffic to the secondary node. If the primary node is faulty, each secondary node may be elected as a new primary node to execute data write requests.

DDS provides an HA connection address to connect to both the primary and secondary nodes and separate read and write operations. In this way, a DDS instance can handle heavy read workloads with ease. In addition, the impact of node faults on services is wakened while the performance is improved.

Read replicas in a replica set instance

A read replica in a replica set instance synchronizes data only from the primary node. It does not ensure high availability and will not be elected as the primary node. A read replica can be accessed through an independent connection. It will not interfere with connections between your applications and the primary and secondary nodes of a replica set instance.

Read replicas are useful when applications need to read large amounts of data from existing instances.

Read replicas in a cluster instance

Read replicas in a cluster instance ensure high availability. If a read replica fails, the system automatically switches workloads to another available read replica or secondary node.

A read replica in a cluster instance can be accessed through an independent connection. It will not interfere with connections between your applications and the primary and secondary nodes of a cluster instance.

All read replicas can be connected using a unified address, so you can expand the read capability of your applications by adding read replicas without modifying the connection address.

A read replica in a cluster instance will not be elected as the primary node.

Read replicas are for scenarios where applications need to read large amounts of data from existing instances, read request load balancing is required, and read replica HA is required.

Constraints

Only replica set instances of versions 3.4, 4.0, 4.2, 4.4 and 5.0 and cluster instances of version 3.4 can have read replicas.
Instances that only have read replicas cannot be created.
Read replicas are used only for processing read requests and do not participate in primary/secondary node election.
A maximum of five read replicas can be added to a replica set instance. For details, see Adding Read Replicas to a Replica Set Instance.
Up to five read replicas can be added to each shard of a cluster DB instance.
Data is asynchronously replicated between the primary node and the read replica, and this process will delay by a few seconds.

Functions

You can change the number of read replicas to meet fluctuating service demands and reduce service costs.
The specifications of a read replica are the same as those of the primary node. Data is automatically synchronized to the read replica.
Resources on the primary node are not occupied. Adding or deleting read replicas does not affect services on the primary node.
Read replicas can be connected independently and do not interfere with existing primary and secondary nodes. For details about read replicas in a replica set instance, see Connecting to Read Replicas Using Mongo Shell.
You can monitor the performance of read replicas.

Billing

After a read replica is added to the current instance, you will be billed for using the VM and disks of the read replica.
The price of a read replica is equal to that of a single node in a replica set instance or a shard node in a cluster instance. For example, if the price of a three-node replica set instance is USD $3,000, the price of a read replica is USD $1,000.

Parent topic: Instances

Previous topic: Single Node

Next topic: Notes and Constraints