tencent cloud

TencentDB for MongoDB

Release Notes and Announcements
Release Notes
Announcements
User Guide
Product Introduction
Overview
Strengths
Use Cases
Cluster Architecture
Product Specifications
Features
Regions and AZs
Terms
Service Regions and Service Providers
Purchase Guide
Billing Overview
MongoDB Pricing
Billing Formula
Payment Overdue
Backup Space Billing
Configuration Adjustment Billing
Getting Started
Quickly Creating an Instance
Connecting to a TencentDB for MongoDB Instance
Reading/Writing Database
Operation Guide
Access Management
Instance Management
Node Management
Version Upgrade
Network Configuration
Monitoring
Backup and Rollback
Database Audit
Data Security
SSL Authentication
Log Management
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
Shard Removal Task: Guide for Confirming the Progress and Troubleshooting Issues
Performance Fine-Tuning
Ops and Development Guide
Development Specifications
Command Support in Sharded Cluster v3.2
Command Support in v3.6
Development Ops
Troubleshooting
Increased Slow Queries
Number of Connections Exceeding Limit
API Documentation
History
Introduction
API Category
Making API Requests
Instance APIs
Backup APIs
Account APIs
Other APIs
Task APIs
Introduction
Data Types
Error Codes
Instance Connection
Shell Connection Sample
PHP Connection Sample
Node.js Connection Sample
Java Connection Sample
Python Connection Sample
Python Read/Write Sample
Go Connection Sample
PHP Reconnection Sample
Product Performance
Test Environment
Test Method
Test Result
FAQs
Cost
Features
Sharded Cluster
Instance
Rollback and Backup
Connection
Data Migration
Others
Service Agreement
Service Level Agreement
Terms of Service
Glossary
Contact Us

Node Overview

PDF
Focus Mode
Font Size
Last updated: 2024-06-26 16:34:04
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.

Help and Support

Was this page helpful?

Help us improve! Rate your documentation experience in 5 mins.

Feedback