The disaster recovery (DR) policy for a single AZ mainly includes two aspects: process/service high availability (HA) and data persistence on disk. Within a single AZ, a stand-alone or single-node cluster instance uses process protection to ensure service HA. When DCS detects a process fault in the Redis instance, it starts a new process to continue to provide services.
l The standard active/standby configuration includes a data persistence function, which not only persists data on the disk of the active node, but also performs incremental synchronization on the standby node. Then, the standby node also independently persists a copy of the data. The active node is responsible for processing daily service requests. However, if the active node fails and meets the switchover conditions, the detection process automatically performs a switch between the active/standby nodes by promoting the standby node to the new active node to achieve failover and ensure HA, ensuring smooth business operation. For the faulty active node, it is updated as the standby node upon recovery.
l Active/standby cluster instances are similar to standard active/standby instances, in which each shard node has a persistent file, and each shard in the cluster has its own active and standby nodes. Each shard independently detects the active node status. If the active node of a shard fails and meets the switchover conditions, the detection process promotes the standby node to the new active node to complete an active/standby switchover operation. The faulty active node is updated as the standby node upon recovery.
Cross-AZ DR Within a Resource Pool
Standard version and cluster version active/standby DCS Redis instances adopt a deployment architecture with active/standby nodes, and support the deployment of active and standby nodes in different AZs (different physical server rooms). The power and network between different AZs are isolated from each other. When the server room where the active node is located fails due to power or network failure, the standby node takes over the service, and the client can establish a connection with the standby node and read/write data as usual.
The figure above illustrates the cross-AZ deployment of active/standby instances. The cluster version active/standby instances are similar to the active/standby instances, for each shard node is deployed across AZs. When buying a Redis instance, you can choose different AZs for deployment (for resource pools that support cross-AZ deployment only).