DWS Cluster DR Scenarios

Function

A DWS disaster recovery (DR) cluster that is homogeneous with the production cluster is deployed in another AZ (in the same region). If the production cluster fails to provide read and write services due to natural disasters or internal faults, the DR cluster becomes the production cluster to ensure service continuity. The following figure shows the architecture.

Figure 1 DR architecture

Application Scenarios

Compared with cluster snapshots and restoration, DR is more suitable for the following scenarios:

• High availability of core services: In scenarios such as financial transactions and real-time analysis, service continuity is required, and a long downtime is unacceptable.
• Compliance and regulatory requirements: Industry regulations require cross-AZ DR.
• Response to natural disasters: If the AZ where the production cluster resides suffers from natural disasters such as earthquakes and floods, remote DR is required.

Example: During a promotion period, an e-commerce platform deploys its core order database cluster in AZ1 and deploys a DR cluster in AZ2 for real-time data synchronization. If AZ1 becomes faulty, the DR cluster in AZ2 can be switched to the production cluster in minutes, ensuring continuity of order services.

DR Features

• Multi-form DR
  • Intra-region DR
  • Data synchronization based on trusted direct connections, covering more DR scenarios
• Low TCO
  • Heterogeneous deployment (logical homogeneity) is supported. You do not need to configure the same hardware specifications for the DR cluster as those for the production cluster.
  • Cluster-level DR
• Visualized management

  Automated and one-click DR drills and recovery simplify O&M.

DR Version Requirements

• Clusters of version 9.1.1.300 or later support DR. Unpredictable exceptions may occur during DR in earlier versions. If you want to use DR in earlier versions, contact technical support.
• Intra-region DR is supported only in cluster version 8.1.1 and later.
• The synchronization resource pool supports cluster-level DR only in cluster version 8.3.0 or later.

DR for Clusters of Different Types

• The Storage-Compute Decoupled cluster does not support the DR function.

• Multi-AZ clusters do not support DR.
• Logical clusters are not supported.

DR Restrictions for Encrypted Clusters

• For encrypted clusters (cluster-level), DR is supported only when the management plane version is 8.6.0 or later and the cluster version is earlier than 9.1.1.200. Only non-encrypted clusters can serve as DR clusters.
• DR is not supported for encrypted clusters running version 9.1.1.200 or later (due to key incompatibility).
• Intra-region DR is supported for encrypted clusters with coupled storage and compute.
• The version and the number of DNs in the DR cluster must be the same as those in the primary cluster. After the DR task is started, the DR cluster becomes an encryption cluster.

DR Cluster Service Capabilities

• During data synchronization, a non-fine-grained DR cluster cannot provide read or write services.
• When the DR task is stopped or becomes abnormal but the DR cluster is normal, the DR cluster can provide the read service. After the DR switchover is successful, the DR cluster can provide the read and write services.

Restrictions on Snapshots and Restoration When DR Is Enabled

• After a DR cluster is created, snapshots can be properly used in the production cluster, but they are disabled in the DR cluster.
• Restoration is disabled for both the production and DR clusters. Ensure that you create required snapshots before creating a DR cluster.

Restrictions on Data Synchronization When DR Is Enabled

• If DR is used when there are cold and hot tables, cold data will not be synchronized to the standby cluster.
• If cold and hot tables are used, cold data is synchronized using OBS.
• DR does not synchronize data from external sources.
• If a cluster has cold and hot data or V3 tables, no DR relationship can be established with the cluster.

Network and Cluster DR Requirements

• DR management refers to dual-cluster DR under the same tenant.
• The DR cluster and the production cluster must be logically homogeneous and in the same type and version.
• The production cluster and DR cluster used for intra-region DR must be in the same VPC.
• If you use a yearly/monthly package for a DR cluster, the cluster will be automatically frozen for a period of time after the package expires, and will be deleted if its subscription is not renewed in time. Renew it in a timely manner to prevent DR exceptions caused by deletion of the DR cluster.

Precautions for DR Switchover

• In intra-region DR, when the production cluster and the DR cluster are switched over, the load balancer is automatically switched to the new production cluster. During the switchover, the connection is interrupted for a short period of time. Do not run service statements to write data during the switchover.
• During intra-region DR, the EIP, intranet domain name, and connection IP address of the original production cluster are not automatically switched with the cluster switchover. The EIP, domain name, or IP address used for connection in the service system needs to be manually switched to the new cluster.