Heterogeneous Disaster Recovery

Scenarios

TaurusDB supports heterogeneous DR instances to ensure high availability. If your DB instance is unavailable due to unknown community bugs or misoperations (for example, large transaction rollbacks), the heterogeneous DR instance (MySQL) can take over the workloads.

The DR instance creation, maintenance, and switchover are all completed by Huawei Cloud and you do not need to do anything.

How DR Switchover Works

Figure 1 Heterogeneous DR mechanism

Before a DR switchover

The business system usually connects to the source TaurusDB instance through the private IP address to read and write data. Data Replication Service (DRS) synchronizes data from the source TaurusDB instance to the DR RDS for MySQL instance in real time to ensure data consistency and high availability. During this process, the DR RDS for MySQL instance is read-only.

After a DR switchover

If the source TaurusDB instance cannot be restored in extreme scenarios, the backend personnel, upon your authorization, will manually switch the private IP address to the DR RDS for MySQL instance. The business system then reads data from and writes data to the DR RDS for MySQL instance. The DR RDS for MySQL instance is in the read/write state and the business system directly connects to this instance for data operations. DRS synchronizes data from the DR RDS for MySQL instance back to the source TaurusDB instance to ensure data consistency. During this process, the source TaurusDB instance remains read-only.

Data migration consists of two phases: full migration and incremental migration.

During full migration, data is pulled from read replicas, which increases the I/O load on the read replicas but does not affect the primary node.

During incremental migration, binlogs are pulled from the primary node, consuming less than 3% of the primary node's performance.

DR Switchover Workflow

1. If your source TaurusDB instance does not run properly, submit a service ticket to confirm that the instance cannot provide services for a long time.
2. Huawei Cloud customer service will inform you about the switchover impact. You need to provide written authorization based on the actual situation.
3. The customer service personnel perform a DR switchover to switch all IP addresses to the DR instance, and the system automatically sets up a DRS reverse synchronization data flow. Then the DR RDS for MySQL instance serves the business system and the source TaurusDB instance is set to read-only.
4. When the source TaurusDB instance recovers, you can evaluate the impact and determine whether to perform a switchback. If a switchback is required, submit a service ticket to the customer service.

Constraints

• Heterogeneous DR instances cannot be created in any of the scenarios listed in the table below.

  Table 1 Constraints

  Scenario	Reason
  Binlog is not enabled.	Binlogs are used to synchronize data between the TaurusDB instance and DR instance.
  binlog_format is not set to ROW.	The DR link may be disconnected.
  There are triggers.	Data may be inconsistent between the source instance and the DR instance.
  There are events.	Data may be inconsistent between the source instance and the DR instance.
  Database names, table names, field names, or indexes contain special characters.	The DR link may be disconnected.
  The data volume exceeds 32 TB.	The capacity of the DR instance has an upper limit.
  The database access is restricted by rules in the security group.	The DR instance cannot connect to the TaurusDB instance to synchronize data.
  The TaurusDB instance is frozen.	The DR instance cannot be created.
  There are no sufficient IP addresses in the VPC subnet.	The DR instance and TaurusDB instance need to use IP addresses in the same subnet.
  There are tables without primary keys or indexes and a large number of operations.	The DR link may be disconnected.
  Cascade operations are performed on tables with foreign keys.	Data may be inconsistent between the source instance and the DR instance.

• Impact of switching to the DR instance

  Table 2 Switchover impact

  Impact	Reason
  High read traffic of the source instance may lead to CPU saturation on the DR instance.	The DR RDS for MySQL instance is a single-node instance. When all traffic of the source instance is routed to this single primary node, the workload will demand more CPU resources.
  Downstream synchronization links using binlog positions may experience errors.	Since binlog positions are inconsistent between the DR and source instances, any synchronization link relying on binlog positions may fail after the switchover. To resolve this, you must either reconfigure the binlog positions or perform a full data synchronization again.

FAQs

• Can I perform a DR switchover on the console?

  Performing a DR switchover is risky and needs authorization from customers. It should be performed by Huawei Cloud customer service personnel.

• What Is the maximum capacity supported by a DR instance?

  An RDS for MySQL instance supports up to 32 TB.

• Will the DR instance's specifications change after the source instance's specifications are changed?

  No. Changing the source instance's specifications does not affect the DR instance's specifications.

• Am I billed for the DR instance?

  Currently, the DR instance is free.

• Will proxy traffic be automatically switched to the DR RDS for MySQL instance?

  Yes. Proxy traffic will be automatically redirected to the DR instance.

• Can I disable the DR instance?

  Once a DR instance is enabled, it cannot be disabled. To ensure your workload availability, you are advised not to disable the DR instance.