TencentDB for Redis® supports deploying replicas across multiple availability zones within the same region, providing higher availability and disaster recovery capabilities compared to single availability zone instances (where the master and replica nodes are in the same availability zone).
Single-AZ deployed instance: Host- and rack-level disaster recovery.
Multi-AZ deployed instance: Host-, rack-, and AZ-level disaster recovery.
Deployment architecture
Description:
LB (Load Balancer): A TencentDB for Redis® instance in standard architecture or cluster architecture has at least three proxies which need to be accessed through LB.
VIP: In Multi-AZ (Availability Zone) instances, a single VIP is used, accessible across the entire region.Redis High Availability (HA) does not cause any changes to the VIP.
Proxy: Access service that implements request routing and is responsible for distributing user data requests.
If read-only replica is enabled, each instance has at least three proxies. For a standard architecture instance, the number of proxies = 3 + (the number of replicas -1); for a cluster architecture instance, the number of proxies = Max [the number of shards the number of replicas; shard quantity 1.5 (rounded up)]
If read-only replica is not enabled, for a standard architecture instance, the number of proxies is 3; for a cluster architecture instance, the number of proxies is shard quantity * 1.5 (rounded up).
Master (Group): "Master" refers to the master node of a TencentDB for Redis® instance in standard architecture; "Master Group" refers to the master nodes of all shards of a TencentDB for Redis® instance in cluster architecture.
Replica (Group): "Replica" refers to the replica nodes of a TencentDB for Redis® instance in standard architecture; "Replica Group" refers to the collection of replica nodes, each of which comes from a different shard of a TencentDB for Redis® instance in the cluster architecture. For a cluster architecture instance, the replicas of a shard are divided into multiple Replica Groups so that these Replica Groups can be deployed in different AZs.
Master AZ: The master AZ refers to the AZ where the master node resides. Unless manually changed in the console, the master AZ will remain the same. If the master node fails, it may be temporarily switched to a replica AZ, and will be automatically switched back to the master AZ in a few minutes once certain conditions are met. This switching back process won't affect your business unless your business uses block commands, such as
blpop or blpush.Failover (HA)
Fault determination: Both Redis standard and cluster architectures use the native Redis Cluster management mechanism, relying on the Gossip protocol for node status determination among cluster nodes. The timeliness of node fault determination depends on the cluster-node-timeout, which has a default value of 15 s. It is recommended not to change this parameter. For node fault determination, please see Native Redis Cluster Design.
Promote a replica to master: TencentDB for Redis® adopts a failover mechanism different from that of Redis Cluster, which gives priority to promoting replicas in the master AZ to reduce access delay of the master AZ. The details are as follows:
Promote the replica if it has the latest data
Promote the replica in the master AZ if all replicas have the same data
Cross-AZ Access
Instance with read-only replica disabled
Read/Write separation disabled (that is, replicas can be written to and read from): Write/read requests in a replica AZ are routed by proxy to the master node, and the master node synchronizes with replica nodes to ensure consistent data across all nodes. In this process, only one cross-AZ access happens.
Instance with read-only replica enabled
Read/Write separation enabled (that is, replicas can only be read from): Write requests are routed by proxy to the master node, but read requests are routed to the replica node in the same AZ as the proxy, so that read requests can get responded by the nearest node.
Note:
There is a 2–5 ms delay during cross-AZ access.
Deployment recommendations
Two-AZ deployment
Two AZs with 1 master and 3 replicas: one master and one replica in the primary AZ, and two replicas in the secondary AZ. Load balancing is implemented across both AZs, with two nodes in each AZ. This ensures that read requests do not cross AZs in case of a single-node failure, and high availability is maintained even if one AZ fails. This solution is suitable for scenarios with high requirements for availability and access latency.
Three-AZ deployment
A deployment with one master node and two replica nodes across three availability zones, with one node in each AZ. This architecture ensures high availability across AZs in case of single host or single AZ failure. It is suitable for scenarios with high availability requirements but less sensitivity to latency.
Related Actions
TencentDB for Redis® supports configuring and viewing multi-AZ information through the console. For more information, see Configuring Multi-AZ.
TencentDB for Redis® supports upgrading from single-AZ to multi-AZ deployment through the console. Please see Upgrading to Multi-AZ Deployment.
TencentDB for Redis® supports enabling and disabling read/write separation through the console. Please see Enable/Disable Read/Write Separation.
Both single-AZ and multi-AZ deployed TencentDB for Redis® instances can be easily accessed at a VIP address. For more information, please see Accessing Multi-AZ Instances.
TencentDB for Redis® supports the automatic failover feature to ensure service availability. Please see Failover for more information.
TencentDB for Redis® provides the automatic failback feature for instances deployed across AZs. Please see Auto Failback for more information.
TencentDB for Redis® provides a manual promotion feature for instances deployed across multiple availability zones. You can deploy the master node to a specified availability zone or replica (group) based on your business requirements. Please see Manually Promoting the Master Node.
To reduce the access latency of a multi-AZ deployed instance, TencentDB for Redis® allows you to read local nodes only. For more information, please see Proximity Access.