Multi-AZ Deployment Solution

Download
Focus Mode
Font Size
Last updated: 2026-07-17 17:35:17
Introduction
An availability zone (AZ) is a physically independent data center with separate power and network resources within the same Region. The multi-AZ high availability solution achieves cross-AZ disaster recovery by distributing MongoDB primary and secondary nodes across multiple AZs. When a single-AZ outage occurs due to infrastructure failure, the system can automatically switch services to a healthy AZ to ensure business continuity.
Business Continuity: It mitigates the risk of single-AZ failures and is suitable for scenarios with high availability requirements, such as financial transactions, government administration, and core e-commerce links.
Compliance Requirements: It meets the compliance standards for intra-city data redundancy and backup set by industry regulators in sectors such as finance and government administration.
Note:
This document covers replica set node roles such as primary node (Primary), secondary node (Secondary), hidden node (Hidden), and read-only node (ReadOnly). For detailed definitions and responsibilities of these roles, refer to the official documentation Cluster Architecture. This document focuses on node deployment methods and disaster recovery mechanisms in multi-AZ scenarios.
TencentDB for MongoDB offers two deployment options: three-AZ (3AZ) and dual-AZ. Both options provide AZ-level disaster recovery capabilities. The dual-AZ option includes two specific configurations: 1 + 1 + 1 (dual AZ + cross-region Hidden) and 2 + 2 (two nodes in each AZ).
Three-AZ Solution
The three-AZ solution is based on the database's native consensus protocol. It consists of three replicas, each holding a complete copy of the data, which are evenly distributed across three physically isolated AZs to achieve AZ-level disaster recovery.
Node Distribution: Replicas are evenly distributed across three independent AZs (AZ1, AZ2, AZ3), with one voting node deployed in each AZ, forming a 1 + 1 + 1 peer-to-peer structure.
High Availability and Disaster Recovery Mechanism: Based on the majority election protocol, when a single-AZ failure causes the primary node to become unavailable, the two remaining AZs still have two active voting nodes. This meets the majority threshold (2 out of 3 voting nodes in this architecture), enabling automatic leader election and seamless service migration without requiring manual intervention or external management platform involvement.
Data Consistency: By setting Write Concern to majority, you can ensure that committed data is not lost when a single-AZ failure occurs.
﻿
Dual-AZ Disaster Recovery Solution
The dual-AZ option is suitable for scenarios where the current region provides only two AZs. We recommend two deployment schemes: 1 + 1 + 1 (dual AZ + cross-region Hidden) and 2 + 2 (two nodes in each AZ). Both schemes provide AZ-level disaster recovery capabilities.
1 + 1 + 1 Solution (Dual AZ + Cross-Region Hidden)
The 1 + 1 + 1 scheme consists of three voting nodes (Primary, Secondary, Hidden). The Primary and Secondary nodes are deployed in the two AZs of the business region, while the Hidden node is deployed in another nearby region. With this third voting node across regions, if any AZ in the business region fails, the replica set still meets the majority requirement. It can automatically elect a leader, similar to the three-AZ scheme, without requiring intervention from the management platform. Additionally, because the Hidden node is located in an independent region, the cluster gains region-level disaster recovery capability, and its overall service capability is equivalent to that of a three-AZ deployment within the same region.
﻿
2 + 2 (2 Nodes per AZ) Solution
The 2 + 2 scheme deploys all nodes within the two AZs of the business region. It consists of four nodes (three voting nodes + one read-only node), introduces no cross-region write latency, and handles AZ-level failures through the collaborative efforts of the database's native protocol and the management platform.
Node Distribution: The replica set consists of three voting nodes (Primary, Secondary, Hidden) + one read-only node (ReadOnly). It is deployed according to the equal principle of "two nodes per AZ". Because the three voting nodes cannot be evenly distributed across two AZs, this inevitably results in an asymmetric 2:1 structure, where one AZ holds two nodes and the other holds one.
High Availability and Disaster Recovery Mechanism: The 2 + 2 scheme provides AZ-level disaster recovery capability. Services can be recovered when any AZ fails. Under the majority write policy, it ensures that data that has been successfully written does not roll back. However, because voting nodes are not evenly distributed across the two AZs, the impact of a failure on each side is not symmetrical, and their recovery paths differ:
Failure of the AZ Holding One Voting Node: The surviving side still holds two voting nodes, which meets the majority requirement. The replica set automatically maintains or elects a Primary, enabling service recovery within seconds.
Failure of the AZ Holding Two Voting Nodes: The surviving side retains only one voting node, which does not meet the majority requirement. Consequently, the replica set cannot elect a leader autonomously and requires intervention from the management platform to reassign voting rights and promote a new Primary. During this period, read-only nodes can still provide external access, ensuring that read operations are not interrupted.
After the failed AZ recovers, the system automatically self-heals: it rebuilds the original nodes and replays the oplog to catch up with incremental data, ultimately returning to the healthy 2 + 2 initial state.
﻿
Note:
Unlike the 1 + 1 + 1 scheme, which relies on a cross-region Hidden node, all nodes in the 2 + 2 scheme are located within the business region, eliminating cross-region write latency. When an AZ-level failure occurs, the management platform automatically performs a failover. After the failover, the surviving AZ maintains a primary-secondary high-availability structure. Once the failed AZ recovers, the system automatically returns to the 2 + 2 state.
Service Access Recommendations
Application Deployment: The application layer also uses a multi-AZ deployment and connects to the MongoDB nodes in the corresponding AZs to minimize cross-AZ access latency.
Configuration Recommendations: In the "dual AZ + cross-region Hidden" (1 + 1 + 1) scheme, services that have enabled read/write majority must guard against increased read/write latency and potential instance load spikes. These issues are caused by cross-AZ latency from the Hidden node when the primary or secondary node fails. It is recommended to evaluate service tolerance in extreme failover scenarios in advance. For services sensitive to latency and load, you can implement a degradation strategy during node failures, such as temporarily disabling read/write majority for non-sensitive services or applying rate limiting.