Data Management:FAQ about Data Disaster Recovery

Description

A backup schedule is abnormal on the Backup Schedules page.

Cause

If your backup schedule is abnormal, at least one task becomes abnormal in the backup schedule. In most cases, the abnormal task may be a full backup task or an incremental backup task. The abnormal task may also be a task of other types.

Solutions

The following table describes the solutions provided by Data Disaster Recovery to help you fix errors for abnormal tasks in a backup schedule.

Procedure

1. In the left-side navigation pane, click Backup Schedules. On the Backup Schedules page, find the abnormal backup schedule and click Rectify in the Status column. You are navigated to the task list page based on the type of the abnormal task in the backup schedule.

   If the abnormal task is a full backup task, you are navigated to the Full Data page. If the abnormal task is an incremental backup task, you are navigated to the Incremental Data page.

   

2. Select a solution based on the abnormal task and your business requirements.

   • If you want to restart an abnormal backup task, find the task and click Restart Backup in the Status column.

     Note

     If you perform full backup, evaluate the impact of full backup on the source database before you restart the abnormal backup task. We recommend that you restart the abnormal backup task during off-peak hours.

     

   • If you want to ignore errors for an abnormal task, find the task and click Ignore Error in the Status column.

     

   • If you want to fix errors for an abnormal full backup task, find the task and move the pointer over the exclamation point (!) icon in the Status column to view the error information. Then, click View Exception Fixing Suggestions in the Status column. If you want to fix errors for an abnormal incremental backup task, click View Incremental Exception Fixing Suggestions in the upper part of the Incremental Data page. You are navigated to the Common errors and troubleshooting for Data Disaster Recovery topic. Search for the error that you want to fix in the "Common Errors and Troubleshooting for Data Disaster Recovery" topic and try to fix the error based on the solutions provided in the topic.

     Note

     If the error that you want to fix is not described in the "Common errors and troubleshooting for Data Disaster Recovery" topic, the error may be caused by an abnormal task of other types. In this case, contact technical support in the DingTalk group (ID: 35585947).

     

Step 1: Assign the AliyunServiceRoleForDBS role to Data Disaster Recovery

The AliyunServiceRoleForDBS role is a Resource Access Management (RAM) role that allows Data Disaster Recovery to access other cloud services. Before Data Disaster Recovery accesses Alibaba Cloud databases that you purchase, such as ApsaraDB RDS instances, ApsaraDB for MongoDB instances, Redis instances, and PolarDB clusters, or self-managed databases hosted on Elastic Compute Service (ECS) instances, the AliyunServiceRoleForDBS role must be assigned to Before Data Disaster Recovery. For more information, see Service-linked roles.

If you use Data Disaster Recovery for the first time, you must assign the AliyunServiceRoleForDBS role to Data Disaster Recovery. For more information about the permissions of the role, see the AliyunServiceRoleForDBS section of the topic.

1. Log on to the DMS console V5.0.

2. In the top navigation bar, choose Security and Specifications (DBS) > Disaster Recovery for Data (DBS) > Disaster Recovery Data Source.

   Note

   If you use the DMS console in simple mode, move the pointer over the icon in the upper-left corner of the DMS console and choose All Features > Security and Specifications (DBS) > Disaster Recovery for Data (DBS) > Disaster Recovery Data Source.

3. In the dialog box that appears, click Authorize DBS SLR.

   Note

   If the Information dialog box does not appear after you log on to the Data Disaster Recovery console, you can skip the subsequent steps and create a backup schedule. For more information, see Manage a backup by using a disaster recovery data source or Create a backup by using a backup schedule list.

4. Click OK.

   The AliyunServiceRoleForDBS role is created for Data Disaster Recovery. You can delete the role based on your business requirements. For more information, see Delete a RAM role.

Step 2: Activate OSS

You are not charged for activating OSS. After you activate OSS, the backup data generated by Data Disaster Recovery can be stored in OSS.

1. Log on to the DMS console V5.0.

2. In the top navigation bar, choose Security and Specifications (DBS) > Disaster Recovery for Data (DBS) > Backup Plan.

   Note

   If you use the DMS console in simple mode, move the pointer over the icon in the upper-left corner of the DMS console and choose All Features > Security and Specifications (DBS) > Disaster Recovery for Data (DBS) > Backup Plan.

3. In the dialog box that appears, click Activate OSS Now.

4. In the dialog box that appears, click Activate Now.

5. On the OSS page, read and agree to the service agreement by selecting the check box and click Activate Now.

Data Disaster Recovery is activated.

AliyunServiceRoleForDBS

Role name: AliyunServiceRoleForDBS

Policy attached to the role: AliyunServiceRolePolicyForDBS

Permissions:

{
  "Version": "1",
  "Statement": [
    {
      "Action": [
        "rds:DescribeDBInstanceNetInfo",
        "rds:DescribeDBInstanceNetInfoForChannel",
        "rds:DescribeTasks",
        "rds:DescribeDBInstances",
        "rds:DescribeFilesForSQLServer",
        "rds:DescribeImportsForSQLServer",
        "rds:DescribeSlowLogRecords",
        "rds:DescribeBinlogFiles",
        "rds:DescribeSQLLogRecords",
        "rds:DescribeParameters",
        "rds:DescribeParameterTemplates",
        "rds:DescribeDBInstanceAttribute",
        "rds:DescribeDatabases",
        "rds:DescribeAccounts",
        "rds:DescribeSecurityIPList",
        "rds:DescribeSecurityIps",
        "rds:DescribeDBInstanceIPArray",
        "rds:DescribeDBInstanceIPArrayList",
        "rds:DescribeDBInstanceSSL",
        "rds:DescribeDBInstanceTDE",
        "rds:CreateDBInstance",
        "rds:CreateAccount",
        "rds:CreateDatabase",
        "rds:ModifySecurityIps",
        "rds:GrantAccountPrivilege",
        "rds:CreateMigrateTask",
        "rds:CreateOnlineDatabaseTask",
        "rds:DescribeMigrateTasks",
        "rds:DescribeOssDownloads",
        "rds:CreateBackup",
        "rds:DescribeBackups",
        "rds:DescribeBackupPolicy",
        "rds:ModifyBackupPolicy",
        "rds:DescribeBackupTasks",
        "rds:DescribeBinlogFiles"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "ecs:DescribeInstance",
        "ecs:DescribeInstances",
        "ecs:DescribeVpcs",
        "ecs:DescribeSecurityGroups",
        "ecs:DescribeSecurityGroupAttribute",
        "ecs:AuthorizeSecurityGroup",
        "ecs:JoinSecurityGroup",
        "ecs:RevokerSecurityGroup"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "kms:ListKeys"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "cms:PutEventRule",
        "cms:PutEventTargets",
        "cms:ListEventRules",
        "cms:ListEventTargetsByRule",
        "cms:DeleteEventRule",
        "cms:DeleteEventTargets"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "polardb:DescribeDBClusterIPArrayList",
        "polardb:DescribeDBClusterNetInfo",
        "polardb:DescribeDBClusters",
        "polardb:ModifySecurityIps",
        "polardb:DescribeDBClusterEndpoints",
        "polardb:DescribeDBClusterAccessWhitelist",
        "polardb:ModifyDBClusterAccessWhitelist"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "dds:DescribeDBInstanceAttribute",
        "dds:DescribeReplicaSetRole",
        "dds:DescribeSecurityIps",
        "dds:DescribeDBInstances",
        "dds:ModifySecurityIps"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "kvstore:DescribeSecurityIps",
        "kvstore:DescribeInstances",
        "kvstore:DescribeAccounts",
        "kvstore:DescribeDBInstanceNetInfo",
        "kvstore:CreateAccount",
        "kvstore:ModifySecurityIps",
        "kvstore:DescribeInstanceAttribute",
        "kvstore:AllocateInstancePrivateConnection",
        "kvstore:DescribeLogicInstanceTopology"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "drds:DescribeDrdsDB",
        "drds:DescribeDrdsDBs",
        "drds:DescribeDrdsDbInstance",
        "drds:DescribeDrdsDbInstances",
        "drds:DescribeDrdsDBIpWhiteList",
        "drds:DescribeDrdsInstances",
        "drds:ModifyDrdsIpWhiteList",
        "drds:CreateDrdsDB",
        "drds:DescribeTable",
        "drds:DescribeTables",
        "drds:ModifyRdsReadWeight",
        "drds:ChangeAccountPassword",
        "drds:CreateDrdsInstance",
        "drds:CreateInstanceAccount",
        "drds:CreateInstanceInternetAddress",
        "drds:DescribeInstanceAccounts"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": [
        "vpc:DescribeVpcs"
      ],
      "Resource": "*",
      "Effect": "Allow"
    },    
    {
       "Action": [
         "bssapi:QueryResourcePackageInstances"
      ],
       "Resource": "*",
       "Effect": "Allow"
    },
    {
      "Action": "hdm:AddHDMInstance",
      "Resource": "*",
      "Effect": "Allow"
    },
    {
      "Action": "ram:DeleteServiceLinkedRole",
      "Resource": "*",
      "Effect": "Allow",
      "Condition": {
          "StringEquals": {
              "ram:ServiceName": "dbs.aliyuncs.com"
          }
        }
    }
  ]
}

Scenario

In the precheck step of configuring a backup schedule in the Data Disaster Recovery console, information about precheck failure is displayed, which indicates that the precheck failed because the value of the binlog_format variable of the source database is not ROW. For more information, see Back up a on-premise database or cloud database from a third-party provider.

Usage notes

• You must set the binlog_format variable to ROW. In ROW mode, the images of the involved rows before and after DML operations are performed are logged. This facilitates data restoration.

• We recommend that you do not set the binlog_format variable to STATEMENT OT MIXED. ROW mode is more stable and reliable.

• If you set the binlog_format variable to ROW, only the binary logs are changed and the database queries are not affected. However, we recommend that you kill all current database connections to ensure that ROW mode takes effect for all database connections.

Procedure

1. Use a privileged account to run the following command in the source database to set binlog_format to ROW.

   SET GLOBAL binlog_format = 'ROW';

   You can run the following command to query the value of binlog_format of a MySQL database:

   SHOW GLOBAL VARIABLES LIKE 'binlog_format';

2. Kill all connections to the database. Otherwise, connected processes may continue to write data in non-ROW mode, which results in inconsistent incremental data.

Prerequisites

• A backup schedule is purchased. For more information, see Create a backup schedule.

  Note

  When you purchase a backup schedule, set the Data Source Type parameter to MySQL and the Backup Method parameter to Logical Backup.

• A read-only ApsaraDB RDS for MySQL instance is created. For more information, see Create a read-only ApsaraDB RDS for MySQL instance.

• Method 1: Configure a backup schedule for a read-only ApsaraDB RDS for MySQL instance by using its public endpoint

  • The public endpoint of the read-only instance is obtained. For more information, see View and manage instance endpoints and ports.

  • The CIDR blocks of the Data Disaster Recovery server are added to the whitelist of the read-only instance. For more information, see Configure an IP address whitelist.

    Note

    When you configure a backup schedule, you can set the Database Location parameter to User-Created Database with Public IP Address <IP Address:Port Number> and click Set Whitelist to obtain the CIDR blocks of the Data Disaster Recovery server.

    

• Method 2: Configure a backup schedule for a read-only ApsaraDB RDS for MySQL instance by using its internal endpoint

  • The internal endpoint of the read-only instance is obtained. A real-time internal IP address is obtained by running the ping command on your local device.

    Important

    The internal IP address that you obtain may change in some scenarios. If the new internal IP address of the read-only instance differs from the internal IP address that is configured in the backup schedule, the backup fails. For more information, see What is the impact of backup on databases?

  • The CIDR blocks of the Data Disaster Recovery server are added to the whitelist of the read-only instance. For more information, see Configure an IP address whitelist.

    Note

    When you configure a backup schedule, you can set the Database Location parameter to RDS Instance and click Set Whitelist to obtain the CIDR blocks of the Data Disaster Recovery server.

    

Precautions

• If you perform a backup over the public endpoint, the binary logs may be delayed. We recommend that you set the Retention Period parameter to a relatively large value on the Backup and Restoration page of the read-only ApsaraDB RDS for MySQL instance. This parameter indicates the retention period of local logs. Default value: 18. Unit: hours.

  

• If you use the internal endpoint to configure a backup schedule and you clone the read-only instance, migrate the instance to another zone, or change the VPC or vSwitch of the instance, the real-time internal IP address that you obtain may change. In this case, the instance fails to be connected, and the backup fails.

  To resolve this issue, you can obtain a new real-time internal IP address and reconfigure a backup schedule. For more information, see the Prerequisites section of this topic and How do I modify the backup source?

Procedure

When you configure a backup schedule for a read-only ApsaraDB RDS for MySQL instance, you can set the Database Location parameter to User-Created Database with Public IP Address <IP Address:Port Number> or Express Connect DB/VPN Gateway/Intelligent Gateway.

How do I obtain the internal and public endpoints of a read-only ApsaraDB RDS for MySQL instance?

1. Go to the Instances page. In the top navigation bar, select the region in which the RDS instance resides. Then, find the RDS instance and click the ID of the instance.

2. On the Basic Information page, click View Details next to the Network Type parameter to obtain the internal and public endpoints of the read-only ApsaraDB RDS for MySQL instance.

   Note

   If you have not applied for a public endpoint for the read-only instance, click Apply for Public Endpoint > OK to apply for a public endpoint. After the public endpoint is applied for, you can obtain the public endpoint.

FAQ

• Q: What are the possible causes and solutions if the source instance fails to be connected when I configure a backup schedule for the instance by using its internal endpoint?

  A: Possible cause: The internal IP address obtained in Method 2 is a real-time internal IP address. If you clone the source read-only instance, migrate the instance to another zone, or change the VPC or vSwitch of the instance, the real-time internal IP address may change. In this case, the source instance fails to be connected, and the backup fails.

  Solution: You can use the internal endpoint of the read-only instance and run the ping command on your local device to obtain a new real-time internal IP address. Then, modify the backup source database and save the configurations.

• Q: Can Data Disaster Recovery back up full data and incremental data of a read-only instance?

  A: Yes.