Help Center/ Document Database Service/ Best Practices/ How Is a DDS Node Going to Be Disconnected and What Can I Do?
Updated on 2026-06-25 GMT+08:00
View PDF
Share

How Is a DDS Node Going to Be Disconnected and What Can I Do?

A replica set consists of three nodes: primary, secondary, and hidden. The three-node architecture is set up automatically, and the three nodes automatically synchronize data with each other to ensure data reliability. Replica sets are recommended for small- and medium-sized service systems that require high availability.

  • Primary node: Primary nodes are used to process both read and write requests.
  • Secondary node: Secondary nodes are used to process read requests only.
  • Hidden node: Hidden nodes are used to back up service data.

You can perform operations on the primary and secondary nodes. If the primary node is faulty, the system automatically selects a new primary node. The following figure shows the replica set architecture.

Figure 1 Three-node replica set architecture

DDS can write data only on the primary node. When data is written to the primary node, oplogs are generated. The secondary and hidden nodes read oplogs from the primary node for replay to ensure data consistency.

The storage capacity of oplogs is determined by the value of oplogSize (10% of the default disk capacity).

How Does Replication Delay Occur?

If the write speed of the primary node exceeds the oplog retrieval and replay speed of the secondary nodes, the primary/secondary replication delay occurs.

When Does a Secondary Node Fall Out of Sync?

Because oplog storage capacity is limited, the earliest oplog entries are overwritten once the upper limit is reached. The secondary node reads the oplog and records the timestamp of the last retrieved oplog entry each time. If the replication delay increases to a certain point where the last replayed oplog position has already been overwritten on the primary, the secondary node can no longer read subsequent oplog entries. The secondary node has become out of sync.

How Do I Prevent Secondary Nodes from Falling Out of Sync?

  • Set writeConcern to majority. In this way, data is written to a majority of nodes, ensuring data consistency.
  • Increase the oplog storage capacity by changing the value of oplogSizePercent on the console. For details, see Modifying DDS DB Instance Parameters.
  • Perform time-consuming DDL operations (such as index creation) and data backup operations during off-peak hours to avoid burst addition, deletion, and modification operations.

    If writeConcern is not set to majority, the data that is not synchronized to the secondary node may be lost when a primary/secondary switchover occurs.