tencent cloud

TencentDB for SQL Server

Release Notes and Announcements
Release Notes
Product Announcements
User Guide
Product Introduction
Overview
Product Architecture
Strengths
Use Cases
Regions and AZs
Major Version Lifecycle Explanation
Features and Differences
Instance Types
Instance Specifications
Storage Types
Common Concepts
Network Environment
License Statement
Purchase Guide
Billing Overview
Product Pricing
Purchase Methods
Renewal Instructions
Payment Overdue
Refund
From Pay-as-You-Go to Monthly Subscription
Instance Adjustment Fees Description
Local Backup Space Billing
Cross-Region Backup Billing
Viewing Bill Details
Getting Started
Creating TencentDB for SQL Server Instance
Connecting to TencentDB for SQL Server Instance
Managing TencentDB for SQL Server Instance
Operation Guide
Constraints and Limits
Usage Specifications and Suggestions
Maintaining Instance
Adjusting Instance Configuration
Read-Only Instance
Network and Security
Account Management
Database Management
Data Security
Parameter Configuration
Monitoring and Alarms
Backup and Restoration 
Log Management
Publish-Subscribe
SSIS
Data Migration (New)
Data Migration (Legacy)
Data Synchronization (DTS) 
Practical Tutorial
TencentDB for SQL Server Methods for Regular Maintenance
TencentDB for SQL Server Optimization of Slow SQL
How to Better Use Tempdb
Cross-Account Backup Restoration
Creating VPC for TencentDB for SQL Server
Connecting Kingdee K/3 WISE to TencentDB for SQL Server
Account Permissions and Permission Control
Enabling and Disabling the CDC Feature
Shrinking a Database
API Documentation
History
Introduction
API Category
Making API Requests
Sales and fee related APIs
Instance Management related APIs
Operation and maintenance management related APIs
Network management related APIs
Account management related APIs
Database management related APIs
Security group management related APIs
Data security encryption related APIs
Parameter configuration related APIs
Extended Event related APIs
Log management related APIs
Read only instance management related APIs
Publish and subscribe related APIs
Backup related APIs
Rollback related APIs
Data migration (cold standby migration) related APIs
SQL Server Integration Services (SSIS) related APIs
Data migration (DTS old version) related APIs
Data Types
Error Codes
FAQs
Overview
Model Selection
Pricing and Selection
Connection and Network
Account and Permission
Backup and Rollback
Data Migration
Publish/Subscribe
Read-Only Instance
Version and Architecture Upgrade
Disk Space and Specification Adjustment
Monitoring and Alarms
Log-Related
Parameter Modification
Features
Performance, Space, and Memory-Related FAQs
Service Agreement
Service Level Agreement
Terms of Service
Performance Evaluation
Performance Test Report
Glossary
Contact Us

Multi-Node

PDF
포커스 모드
폰트 크기
마지막 업데이트 시간: 2025-11-20 15:35:33
TencentDB for SQL Server supports three deployment architectures: single-node, two-node, and multi-node. This document introduces the multi-node architecture.

Background

The database is deployed with a one-primary-multiple-secondary method, which can significantly improve the disaster recovery capability of the database. This ensures the normal and continuous operation of the database. In case of an instance failure that requires HA switch, if the AZ where secondary databases are located encounters an IDC-level incident, it could lead to business interruptions due to the lack of other secondary databases for switching. This issue often results in prolonged recovery times. TencentDB for SQL Server offers a one-primary-multiple-secondary disaster recovery deployment method with high availability. According to the actual business situation and cost, you can choose configurations such as one primary and two secondary nodes, one primary and three secondary nodes, or up to one primary and five secondary nodes. These secondary databases can be deployed across different AZs. Such architecture not only ensures a more secure production environment but also guards against various unexpected situations, including overall data center failures.
In addition, TencentDB for SQL Server enables read-only capabilities for these secondary databases. This means that the secondary databases are not merely the standby for databases, they can also be accessed via the read-only address of the secondary node after the read-only feature on the secondary database is enabled. This helps to offload read requests from the primary node, effectively saving costs associated with read-only instances. Currently, the one-primary-multiple-secondary instance architecture of TencentDB for SQL Server supports enabling read-only access for all secondary databases.

Application Industry

Such as e-commerce/O2O, financial industry, gaming industry, mobile office, data warehouse, data analysis platform, and multi-tenancy SaaS.

Supported Versions

SQL Server 2017, 2019, and 2022 Enterprise.

Architecture

The multi-node architecture adopts the Always On cloud disk architecture design of one-primary-multiple-secondary + compute-storage separation. The primary node provides read/write services, while the secondary nodes provide read-only services and support switching to the primary node within seconds. This achieves multi-AZ disaster recovery and elastic scalability. By dynamically adding or removing nodes and adjusting resources on demand, this architecture can meet the high performance requirements of massive data reads, frequent scaling, and multi-active disaster recovery. In addition, it complies with the strict regulatory requirements of finance, government affairs, and other industries. It applies to complex businesses (such as real-time analysis and multi-tenancy systems) and high performance scenarios requiring read-write separation and can balance business flexibility and stability. Its architecture displayed in the console is shown in the following figure.


Architecture Strengths

Compute-storage separation: Resource decoupling can be achieved by using CVM instances and CBS disks. Configuration adjustments of computing are independent from those of storage, and the traditional fixed CPU/memory ratio and disk capacity limits are eliminated.
Second-level auto scaling: Node addition, node deletion, and node specification adjustment can be performed on demand, and resources can be allocated in minutes to cope with sudden load increases.
Multi-node redundancy: Two to five secondary nodes in cross-AZ deployment mode are supported. Any secondary node can be automatically switched to the primary node in seconds in case of a primary node failure.
Secondary node read-only: Secondary nodes directly provide read services. No additional read-only secondarys are required. In this way, the cost of read performance enhancement can be reduced.

Architecture Diagram



도움말 및 지원

문제 해결에 도움이 되었나요?

피드백