データディザスタリカバリに関する FAQ

説明

バックアップスケジュールは、[バックアップスケジュール] ページで異常です。

原因

バックアップスケジュールが異常な場合、バックアップスケジュール内の少なくとも 1 つのタスクが異常になります。ほとんどの場合、異常なタスクは完全バックアップタスクまたは増分バックアップタスクです。異常なタスクは、他のタイプのタスクである場合もあります。

ソリューション

次の表は、データディザスタリカバリ が提供するソリューションと、バックアップスケジュールにおける異常タスクのエラー修正方法について説明しています。

手順

1. 左側のナビゲーションウィンドウで、[バックアップスケジュール] をクリックします。[バックアップスケジュール] ページで、異常なバックアップスケジュールを見つけ、修正[ステータス] 列の をクリックします。バックアップスケジュール内の異常なタスクの種類に基づいて、タスクリストページに移動します。

   異常なタスクが完全バックアップ タスクの場合、[フルデータ] ページに移動します。異常なタスクが増分バックアップ タスクの場合、[増分データ] ページに移動します。

   

2. 異常なタスクとビジネス要件に基づいてソリューションを選択します。

   • 異常なバックアップ タスクを再開するには、タスクを見つけて、[状態] 列の [バックアップの再開] をクリックします。

     説明

     ソースデータベースの完全バックアップを実行する場合は、異常なバックアップ タスクを再起動する前に、完全バックアップがソースデータベースに及ぼす影響を評価してください。異常なバックアップ タスクは、オフピーク時に再起動することをお勧めします。

     

   • 異常なタスクのエラーを無視する場合は、タスクを見つけて、[状態] 列の [エラーを無視] をクリックします。

     

   • 異常な完全バックアップ タスクのエラーを修正するには、タスクを見つけて、[ステータス] 列の感嘆符（！）アイコンにポインターを移動してエラー情報を表示します。次に、[ステータス] 列の [例外修正の提案を表示] をクリックします。異常な増分バックアップ タスクのエラーを修正するには、[増分データ] ページの上部にある [増分例外修正の提案を表示] をクリックします。データディザスタリカバリの一般的なエラーとトラブルシューティング トピックに移動します。「一般的なエラーとトラブルシューティング」トピックで修正するエラーを検索し、トピックに記載されているソリューションに基づいてエラーを修正してみてください。

     説明

     「データディザスタリカバリの一般的なエラーとトラブルシューティング」のトピックに記載されていないエラーが発生した場合は、他のタイプのタスクの異常が原因である可能性があります。この場合は、DingTalk グループ（ID: 35585947）でテクニカルサポートに連絡してください。

     

Step 1: Assign the AliyunServiceRoleForDBS role to Data Disaster Recovery

AliyunServiceRoleForDBS ロールは、データディザスタリカバリ が他のクラウドサービスにアクセスできるようにする Resource Access Management (RAM) ロールです。データディザスタリカバリ が、ApsaraDB RDS インスタンス、ApsaraDB for MongoDB インスタンス、Redis インスタンス、PolarDB クラスタなど、ご購入いただいた Alibaba Cloud データベース、または Elastic Compute Service (ECS) インスタンスでホストされている自己管理データベースにアクセスする前に、AliyunServiceRoleForDBS ロールを Before Data Disaster Recovery に割り当てる必要があります。詳細については、「サービスにリンクされたロール」をご参照ください。

データディザスタリカバリ を初めて使用する場合は、データディザスタリカバリ に AliyunServiceRoleForDBS ロールを割り当てる必要があります。ロールの権限の詳細については、Topic のAliyunServiceRoleForDBS セクションをご参照ください。

1. DMS コンソール V5.0 にログインします。

2. [セキュリティと仕様 (DBS)] > [データのディザスタリカバリ (DBS)] > [ディザスタリカバリデータソース]

   説明

   DMS コンソールをシンプルモードで使用している場合は、DMS コンソールの左上隅にある アイコンにポインターを移動し、[すべての機能] > [セキュリティと仕様 (DBS)] > [データのディザスタリカバリ (DBS)] > [ディザスタリカバリデータソース] を選択します。

3. 表示されるダイアログボックスで、[DBS SLR を承認] をクリックします。

   説明

   データディザスタリカバリ コンソールにログインした後に情報ダイアログボックスが表示されない場合は、後続のステップをスキップしてバックアップスケジュールを作成できます。詳細については、「ディザスタリカバリデータソースを使用してバックアップを管理する」または「バックアップスケジュールリストを使用してバックアップを作成する」をご参照ください。

4. [OK] をクリックします。

   データディザスタリカバリ 用に AliyunServiceRoleForDBS ロールが作成されます。ビジネス要件に基づいてロールを削除できます。詳細については、「RAM ロールの削除」をご参照ください。

手順 2: OSS をアクティブにする

OSS の有効化は無料です。OSS を有効化すると、Data Disaster Recovery によって生成されたバックアップデータを OSS に保存できます。

1. DMS コンソール V5.0 にログオンします。

2. 上部のナビゲーションバーで、[セキュリティと仕様 (DBS)] > [データのディザスタリカバリ (DBS)] > [バックアップ計画] を選択します。

   説明

   DMS コンソールをシンプルモードで使用している場合は、DMS コンソールの左上隅にある アイコンにポインターを移動し、[すべての機能] > [セキュリティと仕様 (DBS)] > [データのディザスタリカバリ (DBS)] > [バックアッププラン] を選択します。

3. 表示されるダイアログボックスで、[今すぐ OSS を有効にする] をクリックします。

4. 表示されるダイアログボックスで、[今すぐ有効にする] をクリックします。

5. [OSS] ページで、サービス規約を読み、チェックボックスをオンにして同意し、[今すぐ有効にする] をクリックします。

データディザスタリカバリが有効になっています。

AliyunServiceRoleForDBS

Role name: AliyunServiceRoleForDBS サービスロール

Policy attached to the role: AliyunServiceRolePolicyForDBS ロールにアタッチされたポリシー: AliyunServiceRolePolicyForDBS

権限:

{
  "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"
          }
        }
    }
  ]
}

シナリオ

データディザスタリカバリ コンソールでバックアップスケジュールを構成する事前チェック手順では、事前チェックの失敗に関する情報が表示されます。これは、ソースデータベースの binlog_format 変数の値が ROW ではないために事前チェックが失敗したことを示しています。詳細については、「オンプレミス データベースまたはサードパーティプロバイダのクラウドデータベースをバックアップする」をご参照ください。

使用方法

• binlog_format 変数を ROW に設定する必要があります。ROW モードでは、DML 操作の実行前後の関係する行のイメージがログに記録されます。これにより、データ復旧が容易になります。

• binlog_format 変数を STATEMENT または MIXED に設定しないことをお勧めします。ROW モードの方が安定性と信頼性が高くなります。

• binlog_format 変数を ROW に設定した場合、バイナリログのみが変更され、データベースクエリは影響を受けません。ただし、すべてのデータベース接続に対して ROW モードが有効になるように、現在のすべてのデータベース接続を切断することをお勧めします。

手順

1. 特権アカウントを使用して、ソースデータベースで次のコマンドを実行し、binlog_format を ROW に設定します。

   SET GLOBAL binlog_format = 'ROW';

   MySQL データベースの binlog_format の値をクエリするには、次のコマンドを実行します。

   SHOW GLOBAL VARIABLES LIKE 'binlog_format';

2. データベースへのすべての接続を切断します。そうしないと、接続されているプロセスが非 ROW モードでデータの書き込みを続け、増分データの不整合が発生する可能性があります。

前提条件

• A backup schedule is purchased. Create a backup schedule. バックアップスケジュールが購入されます。詳細については、「バックアップスケジュールを作成する」をご参照ください。

  説明

  バックアップスケジュールを購入する場合は、データソースタイプ パラメーターを MySQL に、バックアップ方法 パラメーターを 論理バックアップ に設定します。

• A read-only ApsaraDB RDS for MySQL インスタンスが作成されます。詳細については、「読み取り専用の ApsaraDB RDS for MySQL インスタンスを作成する」をご参照ください。

• 方法 1：パブリックエンドポイントを使用して、読み取り専用の ApsaraDB RDS for MySQL インスタンスのバックアップスケジュールを設定する

  • 読み取り専用インスタンスのパブリックエンドポイントが取得されます。詳細については、「インスタンスのエンドポイントとポートを表示および管理する」をご参照ください。

  • データディザスタリカバリ サーバーの CIDR ブロックが、読み取り専用インスタンスのホワイトリストに追加されます。詳細については、「IP アドレス ホワイトリストを構成する」をご参照ください。

    説明

    バックアップスケジュールを構成する際に、[データベースの場所] パラメーターを [パブリック IP アドレスを持つユーザー作成データベース <IP アドレス:ポート番号>] に設定し、[ホワイトリストの設定] をクリックして データディザスタリカバリ サーバーの CIDR ブロックを取得できます。

    

• 方法 2：内部エンドポイントを使用して、読み取り専用 ApsaraDB RDS for MySQL インスタンスのバックアップスケジュールを設定する

  • 読み取り専用インスタンスの内部エンドポイントが取得されます。ローカル デバイスで ping コマンドを実行することにより、リアルタイムの内部 IP アドレスが取得されます。

    重要

    内部 IP アドレスは、状況によっては変更される場合があります。読み取り専用インスタンスの新しい内部 IP アドレスがバックアップスケジュールで構成されている内部 IP アドレスと異なる場合、バックアップは失敗します。詳細については、「データベースへのバックアップの影響」をご参照ください。

  • データディザスタリカバリ サーバーの CIDR ブロックが、読み取り専用インスタンスのホワイトリストに追加されます。詳細については、「IP アドレスホワイトリストを構成する」をご参照ください。

    説明

    バックアップスケジュールを構成する場合は、[データベースの場所] パラメーターを [RDS インスタンス] に設定し、[ホワイトリストの設定] をクリックして データディザスタリカバリ サーバーの CIDR ブロックを取得できます。

    

注意事項

• パブリックエンドポイント経由でバックアップを実行すると、バイナリログが遅延する可能性があります。読み取り専用の ApsaraDB RDS for MySQL インスタンスの 保持期間[バックアップと復元] ページで、 パラメーターを比較的大きな値に設定することをお勧めします。このパラメーターは、ローカルログの保持期間を示します。 デフォルト値：18。単位：時間。

  

• 内部エンドポイントを使用してバックアップスケジュールを設定し、読み取り専用インスタンスのクローンを作成する、インスタンスを別のゾーンに移行する、またはインスタンスの VPC や vSwitch を変更する場合、取得するリアルタイムの内部 IP アドレスが変更される可能性があります。この場合、インスタンスへの接続に失敗し、バックアップも失敗します。

  To resolve this issue, you can obtain a new real-time internal IP address and reconfigure a backup schedule. For more information, see the 前提条件 section of this topic and バックアップソースを変更するにはどうすればよいですか。 この問題を解決するには、新しいリアルタイムの内部 IP アドレスを取得し、バックアップスケジュールを再構成します。詳細については、このトピックの前提条件 セクションと「バックアップソースを変更するにはどうすればよいですか。」をご参照ください。

手順

読み取り専用 ApsaraDB RDS for MySQL インスタンスのバックアップスケジュールを構成する場合は、[データベースの場所] パラメーターを [パブリック IP アドレスを持つユーザー作成データベース <IP アドレス:ポート番号>] または [express Connect DB/VPN Gateway/インテリジェントゲートウェイ] に設定できます。

読み取り専用 ApsaraDB RDS for MySQL インスタンスの内部エンドポイントとパブリックエンドポイントはどのように取得しますか?

1. [インスタンス] ページに移動します。上部のナビゲーションバーで、RDS インスタンスが存在するリージョンを選択します。次に、RDS インスタンスを見つけ、インスタンスの ID をクリックします。

2. [基本情報] ページで、ネットワークタイプ パラメーターの横にある [詳細の表示] をクリックして、読み取り専用 ApsaraDB RDS for MySQL インスタンスの内部エンドポイントとパブリックエンドポイントを取得します。

   説明

   読み取り専用インスタンスのパブリックエンドポイントを申請していない場合は、[パブリックエンドポイントを申請] > [OK] をクリックして、パブリックエンドポイントを申請します。パブリックエンドポイントが申請されると、パブリックエンドポイントを取得できます。

よくある質問

• Q: インスタンスのバックアップスケジュールを内部エンドポイントを使用して構成するときに、ソースインスタンスが接続できない場合、考えられる原因と解決策は何ですか？

  A: 考えられる原因: 方法 2 で取得した内部 IP アドレスは、リアルタイムの内部 IP アドレスです。ソースの読み取り専用インスタンスをクローンする、インスタンスを別のゾーンに移行する、またはインスタンスの VPC または vSwitch を変更すると、リアルタイムの内部 IP アドレスが変更される可能性があります。この場合、ソースインスタンスへの接続に失敗し、バックアップも失敗します。

  解決策: 読み取り専用インスタンスの内部エンドポイントを使用し、ローカル デバイスで ping コマンドを実行して、新しいリアルタイムの内部 IP アドレスを取得できます。次に、バックアップ ソースデータベースを変更し、構成を保存します。

• Q: データディザスタリカバリ は、読み取り専用インスタンスの完全データと増分データをバックアップできますか?

  A: はい。