Tips

You are advised to comply with the following tips and operation requirements (Table 1 and Table 2) to perform DR and backup to ensure stable task running.

• You are advised to run the DR task at a specific time point during off-peak hours due to the following reasons:
  • Full DR poses certain workload on the source database.
  • To ensure data consistency, tables without a primary key may be locked for 3s during disaster recovery.
  • The data in the DR process may be locked by other transactions for a long period of time, resulting in read timeout.
• You are advised to start the data comparison at a specified time point during off-peak hours to obtain more specific comparison results. Due to slight time difference and continuous operations on data, inconsistent comparison results may be generated, reducing the reliability and validity of the results.

MySQL -> MySQL Single-Active DR

• A DR task may fail due to uncertain causes. The following describes constraints on common operations for your reference.

  Table 1 Operation constraints

  Item	Operation Constraints
  Notes	Requirements in Table 2 apply to the entire DR process. The parameter modification of the service database is not recorded in logs and is not synchronized to the DR database. Therefore, you need to modify the parameters after the DR database is promoted to the primary. DRS does not support disaster recovery of XA transactions. If a high-privilege user created in an external database is not supported by RDS MySQL, the user will not be synchronized to the DR database, for example, the super user. The service database does not support point-in-time recovery (PITR). Binlogs cannot be forcibly deleted. Otherwise, the DR task will fail. If the network is reconnected within 30 seconds, disaster recovery will not be affected. If the network is interrupted for more than 30 seconds, the DR task will fail. If DCC does not support 4 vCPUs | 8 GB or larger instance specifications, the DR task cannot be created. Resumable upload is supported, but data may be repeatedly inserted into a table that does not have a primary key. Migration or synchronization tasks cannot be created when a DR task exists. The DR relationship involves only one primary database. If the external database does not provide the superuser permission, it cannot be set to read-only when it acts as a standby database. Ensure that the data of the standby node is synchronized only from the primary node. Any other write operations will pollute the data in the standby database, data conflicts occur in the DR center and cannot be resolved. If the external database is a standby and read-only database, only the account with the superuser permission can write data to that database. But you still need to ensure that data is written only by this account. Otherwise, the standby database may be polluted, and data conflicts occur in the DR center and cannot be resolved.
  Precautions	A DR task may fail due to the change of the name, account, or port number of the service database. You need to rectify the information and then retry the DR task on the DRS console. Generally, you are advised not to modify the preceding information during disaster recovery. If the service database port is changed during disaster recovery, the DR task fails. Generally, you are advised not to modify the service database port during disaster recovery. During disaster recovery, if the service database is on an RDS DB instance that does not belong the current cloud platform, the IP address cannot be changed. If the service database is on the RDS DB instance on the current cloud platform and the DR task fails due to changes on the IP address, DRS automatically changes the IP address to the correct one. You need to retry the task to continue the disaster recovery. Therefore, changing the IP address is not recommended. Do not write data to the source database during the primary/standby switchover. Otherwise, data pollution or table structure inconsistency may occur, resulting in data inconsistency between the service database and DR database.

• Ensure that your environment configurations meet the following conditions. DRS automatically checks the configurations and provides handling suggestions.

  Table 2 Environment constraints

  Item	Usage Constraints (DRS Automatic Check)
  Database permissions	The service database user must have the following permissions: SELECT, CREATE, ALTER, DROP, DELETE, INSERT, UPDATE, SHOW VIEW, EVENT, INDEX, LOCK TABLES, CREATE VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, RELOAD, REPLICATION SLAVE, REPLICATION CLIENT, and WITH GRANT OPTION. The DR database user must have the following permissions: SELECT, CREATE, ALTER, DROP, DELETE, INSERT, UPDATE, SHOW VIEW, EVENT, INDEX, LOCK TABLES, CREATE VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, RELOAD, REPLICATION SLAVE, REPLICATION CLIENT, and WITH GRANT OPTION. The root account of the RDS MySQL DB instance has the preceding permissions by default.
  Disaster recovery objects	Tables with storage engine different to MyISAM and InnoDB do not support disaster recovery. System tables are not supported. Triggers and events do not support disaster recovery. Accounts that have operation permissions on customized objects in the system database cannot be used for disaster recovery. Backup and disaster recovery, cross-database DDL, and rename operations cannot be performed on some specified service databases. Otherwise, the disaster recovery fails.
  Service database configuration	The binlog of the MySQL service database must be enabled and use the row-based format. If the storage space is sufficient, you are advised to store the service database binlog for as long as possible. The recommended retention period is seven days. The service database username or password cannot be empty. server_id in the MySQL service database must be set. If the service database version is MySQL 5.6 or earlier, the server_id value ranges from 2 to 4294967296. If the service database is MySQL 5.7 or later, the server_id value ranges from 1 to 4294967296. GTID must be enabled for the database. The service database name is a string of 1 to 64 characters, consisting of only lowercase letters, digits, hyphens (-), and underscores (_). The table name and view name in the service database cannot contain non-ASCII characters, or the following characters: '<>/\ If the expire_logs_days value of the database is set to 0, the disaster recovery may fail.
  DR database configuration	The DR DB instance is running properly. If the DR DB instance is a primary/standby instance, the replication status must also be normal. The DR DB instance must have sufficient storage space. The major version of the DR database must be the same as that of the service database. Except the MySQL system database, the DR database must be empty. After a DR task starts, the DR database is set to read-only.

MySQL -> GaussDB(for MySQL) single-active DR

• A DR task may fail due to uncertain causes. The following describes constraints on common operations for your reference.

  Table 3 Operation constraints

  Item	Operation Constraints
  Notes	Requirements in Table 4 apply to the entire DR process. The parameter modification of the service database is not recorded in logs and is not synchronized to the DR database. Therefore, you need to modify the parameters after the DR database is promoted to the primary. DRS does not support disaster recovery of XA transactions. If a high-privilege user created in an external database is not supported by RDS MySQL, the user will not be synchronized to the DR database, for example, the super user. The service database does not support point-in-time recovery (PITR). Binlogs cannot be forcibly deleted. Otherwise, the DR task will fail. If the network is reconnected within 30 seconds, disaster recovery will not be affected. If the network is interrupted for more than 30 seconds, the DR task will fail. If DCC does not support 4 vCPUs | 8 GB or larger instance specifications, the DR task cannot be created. Resumable upload is supported, but data may be repeatedly inserted into a table that does not have a primary key. Migration or synchronization tasks cannot be created when a DR task exists. The DR relationship involves only one primary database. If the external database does not provide the superuser permission, it cannot be set to read-only when it acts as a standby database. Ensure that the data of the standby node is synchronized only from the primary node. Any other write operations will pollute the data in the standby database, data conflicts occur in the DR center and cannot be resolved. If the external database is a standby and read-only database, only the account with the superuser permission can write data to that database. But you still need to ensure that data is written only by this account. Otherwise, the standby database may be polluted, and data conflicts occur in the DR center and cannot be resolved. When DR occurs between an earlier version database and a later version database, service activities must be compatible with both the earlier version and the later version. Otherwise, the DR may fail.
  Precautions	A DR task may fail due to the change of the name, account, or port number of the service database. You need to rectify the information and then retry the DR task on the DRS console. Generally, you are advised not to modify the preceding information during disaster recovery. If the service database port is changed during disaster recovery, the DR task fails. Generally, you are advised not to modify the service database port during disaster recovery. During disaster recovery, if the service database is on an RDS DB instance that does not belong the current cloud platform, the IP address cannot be changed. If the service database is on the RDS DB instance on the current cloud platform and the DR task fails due to changes on the IP address, DRS automatically changes the IP address to the correct one. You need to retry the task to continue the disaster recovery. Therefore, changing the IP address is not recommended. Do not write data to the source database during the primary/standby switchover. Otherwise, data pollution or table structure inconsistency may occur, resulting in data inconsistency between the service database and DR database.

• Ensure that your environment configurations meet the following conditions. DRS automatically checks the configurations and provides handling suggestions.

  Table 4 Environment constraints

  Item	Usage Constraints (DRS Automatic Check)
  Database permissions	The service database user must have the following permissions: SELECT, CREATE, ALTER, DROP, DELETE, INSERT, UPDATE, SHOW VIEW, EVENT, INDEX, LOCK TABLES, CREATE VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, RELOAD, REPLICATION SLAVE, REPLICATION CLIENT, and WITH GRANT OPTION. The DR database user must have the following permissions: SELECT, CREATE, ALTER, DROP, DELETE, INSERT, UPDATE, SHOW VIEW, EVENT, INDEX, LOCK TABLES, CREATE VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, RELOAD, REPLICATION SLAVE, REPLICATION CLIENT, and WITH GRANT OPTION. The root account of the RDS MySQL DB instance has the preceding permissions by default.
  Disaster recovery objects	Tables with storage engine different to MyISAM and InnoDB do not support disaster recovery. System tables are not supported. Triggers and events do not support disaster recovery. Accounts that have operation permissions on customized objects in the system database cannot be used for disaster recovery. Backup and disaster recovery, cross-database DDL, and rename operations cannot be performed on some specified service databases. Otherwise, the disaster recovery fails.
  Service database configuration	The binlog of the MySQL service database must be enabled and use the row-based format. If the storage space is sufficient, you are advised to store the service database binlog for as long as possible. The recommended retention period is seven days. The service database username or password cannot be empty. server_id in the MySQL service database must be set. If the service database version is MySQL 5.6 or earlier, the server_id value ranges from 2 to 4294967296. If the service database is MySQL 5.7 or later, the server_id value ranges from 1 to 4294967296. GTID must be enabled for the database. The service database name is a string of 1 to 64 characters, consisting of only lowercase letters, digits, hyphens (-), and underscores (_). The table name and view name in the service database cannot contain non-ASCII characters, or the following characters: '<>/\ If the expire_logs_days value of the database is set to 0, the disaster recovery may fail.
  DR database configuration	The DR DB instance is running properly. If the DR DB instance is a primary/standby instance, the replication status must also be normal. The DR DB instance must have sufficient storage space. Except the system database, the DR database must be an empty instance. binlog and GTID must be enabled for the DR database.

Cassandra -> GaussDB(for Cassandra) DR

• A dual-active DR task may fail due to uncertain causes. The following describes constraints on common operations for your reference.

  Table 5 Operation constraints

  Item	Operation Constraints
  Precautions	Ensure that data written to Cassandra is written to DMQ the same time.

• Ensure that your environment configurations meet the following conditions. DRS automatically checks the configurations and provides handling suggestions.

  Table 6 Environment constraints

  Item	Usage Constraints (DRS Automatic Check)
  Source database	The source Cassandra database version must be 2.0 or later.
  Destination database	No keyspace with the same name as the source database exists.

  

  DRS supports setting the row-level TTL in Cassandra.

MySQL -> MySQL Dual-Active DR

• A dual-active DR task may fail due to uncertain causes. The following describes constraints on common operations for your reference.

  Table 7 Operation constraints

  Item	Operation Constraints
  Notes	Requirements in Table 8 apply to the entire DR process. Dual-active DR supports backup in backward and forward directions. Due to certain uncontrollable factors, data may be inconsistent between the two sides. For example, if the load of active database 1 is too heavy and the load of active database 2 is light, data updates on the active database 1 synchronized to the active database 2 will be delayed due to the heave load, as a result, the operation sequence is changed and data becomes inconsistency. Therefore, divide data by unit (database, table, or row) and ensure the unit on one database is responsible for data read and write while on the other is read-only. In essence, in dual-active DR, both the databases play the active role but work differently. For details about common scenarios, see Common Multi-Active DR Scenarios. If the same data on both databases is updated simultaneously, data conflicts may occur. DRS resolves the conflict by overwriting the previous settings with the last settings. When the deletion operation is performed, data is deleted and DRS does not perform any operation. When the insert operation is performed, DRS updates data with the latest inserted data. When the update operation is performed, the original data has been updated and DRS directly insert the new data. Primary key conflicts between the two sides need to be avoided. For example, you can use a UUID or the primary key rule of region+auto-increment ID to avoid conflicts. If the synchronization delay takes a long time due to connection interruption or network issues, you need to determine whether your services can tolerant the long-term delay. The dual-active DR is different from the single-active DR. Therefore, no active/standby switchover is required.
  Precautions	The DR latency is uncontrollable. Therefore, DDL operations must be performed when no service is running, and both RPO and RTO are zero and latency is kept within 30 seconds on active database 1. Do not perform DDL operations on active database 2. (DRS synchronizes only the DDL operations on active database 1 to active database 2.) Ensure that the tables, columns, and rows are consistent in both the databases. (The table structures of both the active databases are consistent.) A backward task can be started only when the forward task is in the DR process and both RPO and RTO are less than 60s. After the dual-active DR task is in the DR process, perform tests on the active database 2 first. If the test results meet the requirements, switch certain service traffic to the active database 2.

• Ensure that your environment configurations meet the following conditions. DRS automatically checks the configurations and provides handling suggestions.

  Table 8 Environment constraints

  Item	Usage Constraints (DRS Automatic Check)
  Database permissions	The service database user must have the following permissions: SELECT, CREATE, ALTER, DROP, DELETE, INSERT, UPDATE, SHOW VIEW, EVENT, INDEX, LOCK TABLES, CREATE VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, RELOAD, REPLICATION SLAVE, REPLICATION CLIENT, and WITH GRANT OPTION. The DR database user must have the following permissions: SELECT, CREATE, ALTER, DROP, DELETE, INSERT, UPDATE, SHOW VIEW, EVENT, INDEX, LOCK TABLES, CREATE VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, RELOAD, REPLICATION SLAVE, REPLICATION CLIENT, and WITH GRANT OPTION. The root account of the RDS MySQL DB instance has the preceding permissions by default.
  Disaster recovery objects	Tables with storage engine different to MyISAM and InnoDB do not support disaster recovery. System tables are not supported. Triggers and events do not support disaster recovery. Accounts that have operation permissions on customized objects in the system database cannot be used for disaster recovery. DDL operations cannot be executed on the active database 2.
  Service database configuration	The binlog of the MySQL service database must be enabled and use the row-based format. If the storage space is sufficient, you are advised to store the service database binlog for as long as possible. The recommended retention period is seven days. The service database cannot contain empty accounts or passwords. server_id in the MySQL service database must be set. If the service database version is MySQL 5.6 or earlier, the server_id value ranges from 2 to 4294967296. If the service database is MySQL 5.7 or later, the server_id value ranges from 1 to 4294967296. GTID must be enabled for the database. The service database name is a string of 1 to 64 characters, consisting of only lowercase letters, digits, hyphens (-), and underscores (_). The table name and view name in the service database cannot contain non-ASCII characters, or the following characters: '<>/\ If the expire_logs_days value of the database is set to 0, the disaster recovery may fail.
  DR database configuration	The DR DB instance is running properly. If the DR DB instance is a primary/standby instance, the replication status must also be normal. The DR DB instance must have sufficient storage space. The major version of the active database 1 must be the same as that of the active database 2. In addition to the MySQL system database, the active database 2 must be an empty instance. After the forward task is started, the active database 2 is set to read-only. After the backward task is started and DR is performed, the active database 2 is restored to read-write.