- Release Notes and Announcements
- User Guide
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Access Management
- Instance Management
- Node Management
- Version Upgrade
- Public Network Access
- Monitoring
- Backup and Rollback
- Data Security
- SSL Authentication
- Database Management
- Multi-AZ Deployment
- Disaster Recovery/Read-Only Instances
- Parameter Configuration
- Recycle Bin
- Task Management
- Performance Optimization
- Data Migration Guide
- Practical Tutorial
- Optimizing Indexes to Break Through Read/Write Performance Bottlenecks
- Troubleshooting Mongos Load Imbalance in Sharded Cluster
- Considerations for Using Shard Clusters
- Sample of Reading and Writing Data in MongoDB Instance
- Methods for Importing and Exporting Data Based on CVM Connected with MongoDB
- What to Do for Errors of Repeated Instance Creation and Deletion of Databases with the Same Names?
- Troubleshooting MongoDB Connection Failures
- Performance Fine-Tuning
- Ops and Development Guide
- Troubleshooting
- API Documentation
- History
- Introduction
- API Category
- Making API Requests
- Instance APIs
- RenameInstance
- OfflineIsolatedDBInstance
- ModifyDBInstanceSpec
- IsolateDBInstance
- DescribeSpecInfo
- DescribeDBInstances
- DescribeClientConnections
- CreateDBInstanceHour
- AssignProject
- RenewDBInstances
- DescribeSlowLogs
- DescribeSlowLogPatterns
- InquirePriceRenewDBInstances
- InquirePriceModifyDBInstanceSpec
- InquirePriceCreateDBInstances
- DescribeDBInstanceDeal
- DescribeSecurityGroup
- DescribeInstanceParams
- ModifyDBInstanceSecurityGroup
- ModifyDBInstanceNetworkAddress
- Backup APIs
- Account APIs
- Task APIs
- Other APIs
- Data Types
- Error Codes
- Instance Connection
- FAQs
- Service Agreement
- Glossary
- Contact Us
- Release Notes and Announcements
- User Guide
- Product Introduction
- Purchase Guide
- Getting Started
- Operation Guide
- Access Management
- Instance Management
- Node Management
- Version Upgrade
- Public Network Access
- Monitoring
- Backup and Rollback
- Data Security
- SSL Authentication
- Database Management
- Multi-AZ Deployment
- Disaster Recovery/Read-Only Instances
- Parameter Configuration
- Recycle Bin
- Task Management
- Performance Optimization
- Data Migration Guide
- Practical Tutorial
- Optimizing Indexes to Break Through Read/Write Performance Bottlenecks
- Troubleshooting Mongos Load Imbalance in Sharded Cluster
- Considerations for Using Shard Clusters
- Sample of Reading and Writing Data in MongoDB Instance
- Methods for Importing and Exporting Data Based on CVM Connected with MongoDB
- What to Do for Errors of Repeated Instance Creation and Deletion of Databases with the Same Names?
- Troubleshooting MongoDB Connection Failures
- Performance Fine-Tuning
- Ops and Development Guide
- Troubleshooting
- API Documentation
- History
- Introduction
- API Category
- Making API Requests
- Instance APIs
- RenameInstance
- OfflineIsolatedDBInstance
- ModifyDBInstanceSpec
- IsolateDBInstance
- DescribeSpecInfo
- DescribeDBInstances
- DescribeClientConnections
- CreateDBInstanceHour
- AssignProject
- RenewDBInstances
- DescribeSlowLogs
- DescribeSlowLogPatterns
- InquirePriceRenewDBInstances
- InquirePriceModifyDBInstanceSpec
- InquirePriceCreateDBInstances
- DescribeDBInstanceDeal
- DescribeSecurityGroup
- DescribeInstanceParams
- ModifyDBInstanceSecurityGroup
- ModifyDBInstanceNetworkAddress
- Backup APIs
- Account APIs
- Task APIs
- Other APIs
- Data Types
- Error Codes
- Instance Connection
- FAQs
- Service Agreement
- Glossary
- Contact Us
The replica set architecture of TencentDB for MongoDB achieves high availability and read/write separation by deploying multiple types of nodes. Each replica set instance consists of one primary node, one or multiple secondary nodes, and one hidden node.
The sharded cluster architecture implements the horizontal capacity expansion of data based on the replica set architecture by combining multiple replica sets, each of which is a shard.
Each node is as described below:
Node | Feature | Description |
Primary node | It is responsible for handling read/write operations. | There can be only one primary node in each replica set instance. |
Secondary node | It replicates the data of the primary node by periodically polling the oplogs of the primary node with data consistency guaranteed. When the original primary node fails, a new primary node will be elected from multiple secondary nodes to ensure the high availability. | When a client connects to a secondary node, it has read-only access and cannot write data. A secondary node can be expanded as described in Adding Secondary Node. A secondary node can be promoted to primary node as described in Promoting Secondary Node to Primary Node. |
Hidden node | A secondary node will be designated as the hidden node by default for each newly purchased instance. It serves as an invisible replica node to back up data. When a secondary or a read-only node fails, this hidden node and the faulty secondary node can be switched to new secondary nodes, thereby achieving high availability. | There can be only one hidden node in each replica set instance. It is not possible to delete a secondary node that has been designated as a hidden node. A hidden node is not included in the "Primary Node's Replica List" and will not be elected as the primary node. However, it can participate in the voting process to elect the primary node. |
Read-only node | If the read-only replica feature is enabled, the system will set one or more secondary nodes as read-only nodes. Read-only nodes are primarily used in scenarios with a large volume of read requests. They synchronize data from the primary or secondary nodes through the operation log. The system automatically routes read requests to the read-only nodes to reduce the access pressure on the primary node. | Read-only nodes do not participate in the election of the primary node. There can be multiple read-only nodes in each replica set instance. For more information, see Adding Read-Only Node. |
Yes
No
Was this page helpful?