The two-node local disk instances of TencentDB for SQL Server support the SQL Server 2012, 2014, 2016, 2017, and 2019 Enterprise editions. The two-node cloud disk instances support the SQL Server 2012, 2014, 2016, 2017, 2019, 2022, and 2025 Enterprise editions. Among these, the primary/secondary architectures differ across editions and fall into the following two scenarios.
Scenario 1
If the edition is SQL Server 2012, 2014, or 2016 Enterprise, the primary/secondary architecture of the two-node instance consists of a one-primary-one-mirror SQL Server database. It is deployed across racks or AZs. Each database corresponds to a set of monitoring agents, which perform real-time monitoring of the database via heartbeat. Its architecture displayed in the console is shown in the following figure.
Tencent Cloud Management Cluster: It consists of independently deployed decision-scheduling and configuration clusters. Serving as the management and scheduling center for the cluster, it primarily manages the normal operation of database node groups, access gateway clusters, and COS.
COS: provides data disaster recovery services and cold backup data.
Access Gateway Cluster: provides a single external IP address. If a data node fails over, the IP address for users to connect to the instance remains unchanged.
The scaling of read-only instances is implemented through the publish/subscribe model.
Note:
The mirror (Mirror) maintains a complete data replica and does not provide read/write services itself. It achieves data synchronization by receiving update logs from the Principal and allows snapshots to be created for reporting. In a mirroring cluster, data synchronization between the Principal and the Mirror is implemented through transaction logs. SQL Server transaction logs are at the Database level, not the instance level. Each Database has its own transaction log. SQL Server mirroring is implemented at the Database level.
Scenario 2
If the edition is SQL Server 2017, 2019, 2022, or 2025 Enterprise, the primary/secondary architecture of the two-node instance adopts the Always On architecture (including one-primary-one-secondary). The primary and secondary nodes are deployed across racks or AZs. Each database corresponds to a set of monitoring agents, which perform real-time monitoring of the database via heartbeat. Its architecture displayed in the console is shown in the following figure.
Tencent Cloud Management Cluster: It consists of independently deployed decision-scheduling and configuration clusters. Serving as the management and scheduling center for the cluster, it primarily manages the normal operation of database node groups, access gateway clusters, and COS.
COS: provides data disaster recovery services and cold backup data.
Access Gateway Cluster: provides a single external IP address. If a data node fails over, the IP address for users to connect to the instance remains unchanged.
Note:
The basic synchronization process of Always On:
Logs (Commit, Log Block Write) from the Primary node are flushed from the Log Cache to the disk. At the same time, the Log Capture of the Primary node also sends the logs to all other Replica nodes. The Log Receive thread on the corresponding node flushes the received logs from the Log Cache to the disk as well. Finally, the Redo Thread applies these logs and flushes them to the data files.
AZs Supported by Two-Node Architecture
|
Guangzhou ap-guangzhou | Guangzhou Zone 3 ap-guangzhou-3 | × | ✓ |
| Guangzhou Zone 6 ap-guangzhou-6 | ✓ | ✓ |
| Guangzhou Zone 7 ap-guangzhou-7 | ✓ | ✓ |
Shanghai ap-shanghai | Shanghai Zone 2 ap-shanghai-2 | ✓ | ✓ |
| Shanghai Zone 3 ap-shanghai-3 | × | ✓ |
| Shanghai Zone 4 ap-shanghai-4 | ✓ | ✓ |
| Shanghai Zone 5 ap-shanghai-4 | ✓ | ✓ |
Shanghai Finance ap-shanghai-fsi | Shanghai Finance Zone 3 ap-shanghai-fsi-3 | ✓ | × |
| Shanghai Finance Zone 4 ap-shanghai-fsi-4 | ✓ | × |
Nanjing ap-nanjing | Nanjing Zone 1 ap-nanjing-1 | ✓ | ✓ |
| Nanjing Zone 2 ap-nanjing-2 | ✓ | ✓ |
Beijing ap-beijing | Beijing Zone 1 ap-beijing-1 | × | ✓ |
| Beijing Zone 3 ap-beijing-3 | ✓ | ✓ |
| Beijing Zone 4 ap-beijing-4 | × | × |
| Beijing Zone 5 ap-beijing-5 | × | ✓ |
| Beijing Zone 6 ap-beijing-6 | ✓ | ✓ |
| Beijing Zone 7 ap-beijing-7 | ✓ | ✓ |
Beijing Finance ap-beijing-fsi | Beijing Finance Zone 1 ap-beijing-fsi-1 | ✓ | × |
| Beijing Finance Zone 2 ap-beijing-fsi-2 | ✓ | × |
Chengdu ap-chengdu | Chengdu Zone 1 ap-chengdu-1 | ✓ | ✓ |
| Chengdu Zone 2 ap-chengdu-2 | ✓ | ✓ |
Chongqing ap-chongqing | Chongqing Zone 1 ap-chongqing-1 | ✓ | ✓ |
Hong Kong (China) ap-hongkong | Hong Kong (China) Zone 1 ap-hongkong-1 | × | ✓ |
| Hong Kong (China) Zone 2 ap-hongkong-2 | ✓ | ✓ |
| Hong Kong (China) Zone 3 ap-hongkong-3 | ✓ | ✓ |
|
Singapore ap-singapore | Singapore Zone 1 ap-singapore-1 | × | × |
| Singapore Zone 2 ap-singapore-2 | × | × |
| Singapore Zone 3 ap-singapore-3 | ✓ | × |
| Singapore Zone 4 ap-singapore-4 | ✓ | × |
Jakarta ap-jakarta | Jakarta Zone 1 ap-jakarta-1 | ✓ | × |
| Jakarta Zone 2 ap-jakarta-2 | ✓ | × |
Bangkok ap-bangkok | Bangkok Zone 1 ap-bangkok-1 | ✓ | × |
| Bangkok Zone 2 ap-bangkok-2 | ✓ | × |
Seoul ap-seoul | Seoul Zone 1 ap-seoul-1 | ✓ | ✓ |
| Seoul Zone 2 ap-seoul-2 | ✓ | × |
Tokyo ap-tokyo | Tokyo Zone 1 ap-tokyo-1 | ✓ | ✓ |
| Tokyo Zone 2 ap-tokyo-2 | ✓ | ✓ |
|
Virginia na-ashburn | Virginia Zone 1 na-ashburn-1 | ✓ | × |
| Virginia Zone 2 na-ashburn-2 | ✓ | × |
Frankfurt eu-frankfurt | Frankfurt Zone 1 eu-frankfurt-1 | ✓ | × |
| Frankfurt Zone 2 eu-frankfurt-2 | ✓ | × |
Silicon Valley na-siliconvalley | Silicon Valley Zone 1 na-siliconvalley-1 | ✓ | ✓ |
| Silicon Valley Zone 2 na-siliconvalley-2 | ✓ | ✓ |
São Paulo sa-saopaulo | São Paulo Zone 1 sa-saopaulo-1 | ✓ | × |
|
Middle East (Riyadh) me-riyadh | Riyadh Zone 1 me-saudi-arabia-1 | ✓ | × |
| Riyadh Zone 2 me-saudi-arabia-2 | ✓ | × |
Note:
The names and trademarks of SQL Server, Windows, .NET, and others are owned by Microsoft Corporation or its affiliates. Their use in this document is solely for the purpose of illustrating product compatibility and support.