データディザスタリカバリの一般的なエラーとトラブルシューティング - Data Management

データディザスタリカバリでバックアップスケジュールを設定、バックアップスケジュールまたはリストアタスクの事前チェック、リストアタスクの実行を行う際にエラーが発生することがあります。このトピックでは、一般的なエラーとこれらのエラーのトラブルシューティング方法について説明します。

説明

発生したエラーがこのトピックで説明されていない場合、またはこのトピックで提供されている解決策を使用しても問題が解決しない場合は、DingTalk グループ（ID：35585947）のテクニカルサポートにお問い合わせください。

エラータイプ別の一般的なエラー一覧

バックアップスケジュールを設定する際に発生する可能性のある一般的なエラー

詳細については、「ソースデータベースへの接続テストに失敗しました」をご参照ください。

バックアップスケジュールまたはリストアタスクの事前チェックを行う際に発生する可能性のある一般的なエラー

詳細については、「ソースデータベースへの接続チェックに失敗しました」をご参照ください。
詳細については、「ソースデータベースの権限の確認に失敗しました」をご参照ください。
詳細については、「OSS への接続チェックに失敗しました」をご参照ください。
詳細については、「ソースデータベースでバイナリロギング機能が有効になっているかどうかの確認に失敗しました」をご参照ください。
詳細については、「ソースデータベースのバイナリログ形式の確認に失敗しました」をご参照ください。
詳細については、「ソースデータベースの binlog_row_image パラメータが FULL に設定されているかどうかの確認に失敗しました」をご参照ください。
詳細については、「ソースデータベースのサーバー ID の確認に失敗しました」をご参照ください。
詳細については、「ソースデータベースにバイナリログファイルが存在するかの確認に失敗しました」をご参照ください。
詳細については、「ストレージエンジンの確認に失敗しました」をご参照ください。
詳細については、「MySQL データベースのパスワード形式の確認に失敗しました」をご参照ください。
詳細については、「オブジェクト名の競合」をご参照ください。

高度なダウンロード機能で返される可能性のある一般的なエラーコード

詳細については、「DBS-DownloadTask.Region」をご参照ください。
詳細については、「DBS-DownloadTask.InstanceInfo」をご参照ください。
詳細については、「DBS-DownloadTask.DbType」をご参照ください。
詳細については、「DBS-DownloadTask.CustinId」をご参照ください。
詳細については、「DBS-DownloadTask.CustinName」をご参照ください。
詳細については、「DBS-DownloadTask.user」をご参照ください。
詳細については、「DBS-DownloadTask.Instance.Version」をご参照ください。
詳細については、「DBS-DownloadTask.Instance.Storage.Type」をご参照ください。
詳細については、「DBS-DownloadTask.Instance.Param」をご参照ください。
詳細については、「DBS-DownloadTask」をご参照ください。

タスクの実行時に返される可能性のある一般的なエラーコード

詳細については、「DBS-000000」をご参照ください。
詳細については、「DBS-000001」をご参照ください。
詳細については、「DBS-000002」をご参照ください。
詳細については、「DBS-000003」をご参照ください。
詳細については、「DBS-000004」をご参照ください。
詳細については、「DBS-000005」をご参照ください。
詳細については、「DBS-000006」をご参照ください。
詳細については、「DBS-000007」をご参照ください。
詳細については、「DBS-002003」をご参照ください。
詳細については、「DBS-002009」をご参照ください。
詳細については、「DBS-102001」をご参照ください。
詳細については、「DBS-105001」をご参照ください。
詳細については、「DBS-106001」をご参照ください。
詳細については、「DBS-202002」をご参照ください。
詳細については、「DBS-203101」をご参照ください。
詳細については、「DBS-203102」をご参照ください。
詳細については、「DBS-203103」をご参照ください。
詳細については、「DBS-203104」をご参照ください。
詳細については、「DBS-203201」をご参照ください。
詳細については、「DBS-203202」をご参照ください。
詳細については、「DBS-203203」をご参照ください。
詳細については、「DBS-203205」をご参照ください。
詳細については、「DBS-203206」をご参照ください。
詳細については、「DBS-203240」をご参照ください。
詳細については、「DBS-203301」をご参照ください。
詳細については、「DBS-203302」をご参照ください。
詳細については、「DBS-301005」をご参照ください。
詳細については、「DBS-301502」をご参照ください。
詳細については、「DBS-301503」をご参照ください。
詳細については、「DBS-301504」をご参照ください。
詳細については、「DBS-301505」をご参照ください。
詳細については、「DBS-302035」をご参照ください。
詳細については、「DBS-400001」をご参照ください。
詳細については、「DBS-999999 またはエラーコードなし」をご参照ください。

バックアップスケジュールを設定する際に発生する可能性のある一般的なエラー

ソースデータベースへの接続テストに失敗しました

シナリオ：バックアップスケジュールを設定する際に接続テストが失敗します。

原因：

データベースアカウント名またはパスワードが無効です。
データベースがデータディザスタリカバリの IP アドレスからのアクセスを拒否しています。
データベースが存在するサーバーまたはネットワークにファイアウォールが設定されています。
ネットワーク通信が異常です。

解決策：

データディザスタリカバリコンソールで [チェック] をクリックして、接続テストの失敗の詳細を表示します。
次のチェックを実行して問題をトラブルシューティングします。
- データベースアカウント名またはパスワードが無効であるか、データベースがデータディザスタリカバリの IP アドレスからのアクセスを拒否しているかどうかを確認します。
  1. データベースアカウント名とパスワードが有効かどうかを確認します。
    ソースデータベースに接続できるサーバーを見つけます。サーバー上で、バックアップスケジュールを設定する際に指定したデータベースアカウント名とパスワードを使用してデータベースに接続します。これにより、データベースアカウント名とパスワードが有効かどうかを確認できます。データベースアカウント名またはパスワードが無効な場合は、有効なデータベースアカウント名とパスワードを指定して、接続を再テストします。
  2. データベースアカウント名とパスワードが有効な場合は、データベースがデータディザスタリカバリの IP アドレスをブロックしているかどうかを確認します。
    - データベースが MySQL データベースの場合は、MySQL クライアントを使用してデータベースに接続し、次の SQL 文を実行して、指定したデータベースアカウントの IP アドレスを取得します。次に、その IP アドレスからデータベースへのリモートアクセスが許可されているかどうかを確認します。
      SELECT host,user,authentication_string,password_expired,account_locked FROM mysql.user WHERE user='[$Username]';
      説明
      [$Username] を、バックアップスケジュールを設定する際に指定したデータベースアカウントに置き換えます。
    - データベースが SQL Server データベースの場合は、
      - バックアップゲートウェイがソースデータベースサーバーにインストールされている場合は、[アドレス] パラメータを localhost に設定します。
      - データベースが存在するサーバーにファイアウォールが設定されているかどうかを確認します。さらに、ソースデータベースのエンドポイントまたはトリガーがデータディザスタリカバリの IP アドレスからのアクセスを拒否しているかどうかを確認します。
    - データベースが Oracle データベースの場合は、sqlnet.ora ファイルの TCP.VALIDNODE_CHECKING パラメータが YES に設定されているかどうかを確認します。パラメータが YES に設定されている場合、データベースはデータディザスタリカバリの IP アドレスからのアクセスを拒否します。
- データベースが存在するサーバーにファイアウォールが設定されており、サーバーへのアクセスを拒否するようにファイアウォールポリシーが設定されているか、ネットワーク通信が異常であるかどうかを確認します。
  1. データベースが存在するサーバーにファイアウォールが設定されており、サーバーへのアクセスを拒否するようにファイアウォールポリシーが設定されているかどうかを確認します。
    - データベースが Windows サーバーにデプロイされている場合は、コントロールパネルから Windows Defender ファイアウォールを見つけて、サーバーへのアクセスを拒否するようにファイアウォールポリシーが設定されているかどうかを確認します。
    - データベースが Linux サーバーにデプロイされている場合は、iptables -L コマンドを実行して、サーバーへのアクセスを拒否するようにファイアウォールポリシーが設定されているかどうかを確認します。
    - ソースデータベースが Elastic Compute Service（ECS）インスタンスにデプロイされている場合は、データディザスタリカバリサーバーの CIDR ブロックが ECS インスタンスのセキュリティグループルールに追加されているかどうかを確認します。詳細については、「セキュリティグループルールの追加」をご参照ください。データディザスタリカバリサーバーの CIDR ブロックは、データディザスタリカバリコンソールで取得できます。
  2. データベースのネットワークファイアウォールで、データディザスタリカバリサーバーの CIDR ブロックからのアクセスが許可されているかどうかを確認します。この例では、Cloud Firewall を使用しています。
    1. Cloud Firewall コンソールにログインします。左側のナビゲーションウィンドウで、[アクセス制御] を選択します。
    2. [インターネット境界] ページで、データディザスタリカバリサーバーの CIDR ブロックからのアクセスを拒否するように Cloud Firewall のポリシーが設定されているかどうかを確認します。データディザスタリカバリサーバーの CIDR ブロックは、データディザスタリカバリコンソールで取得できます。
    説明
    エラーがファイアウォールによって発生したものではないが、Telnet 接続テストが引き続き失敗する場合は、データディザスタリカバリのネットワーク通信が異常である可能性があります。DingTalk グループのテクニカルサポートにお問い合わせください。

バックアップスケジュールまたはリストアタスクの事前チェックを行う際に発生する可能性のある一般的なエラー

ソースデータベースへの接続チェックに失敗しました

シナリオ：バックアップスケジュールまたはリストアタスクを開始する際に、バックアップスケジュールまたはリストアタスクの事前チェックが失敗します。

原因：

データベースアカウント名またはパスワードが無効です。
データベースがデータディザスタリカバリの IP アドレスからのアクセスを拒否しています。
データベースが存在するサーバーまたはネットワークにファイアウォールが設定されています。
ネットワーク通信が異常です。

解決策：詳細については、このトピックの「ソースデータベースへの接続テストに失敗しました」セクションをご参照ください。

ソースデータベースの権限の確認に失敗しました

原因：

バックアップスケジュールに指定したデータベースアカウントに、データベースにアクセスするための権限がありません。
リストアタスクに指定したデータベースアカウントに、データベースにデータを書き込んだり、データベース内のテーブルを更新するための権限がありません。

解決策：使用するデータベースアカウントの権限を確認します。データベースアカウントに十分な権限がない場合は、必要な権限をデータベースアカウントに付与するか、必要な権限を持つ別のデータベースアカウントを使用することをお勧めします。

説明

バックアップスケジュール：バックアップスケジュールのデータベースアカウントを変更する方法の詳細については、「バックアップソースを変更するにはどうすればよいですか？」をご参照ください。
リストアタスク：別のリストアタスクを設定することをお勧めします。事前チェックに合格したリストアタスクは削除できます。

OSS への接続チェックに失敗しました

原因：

バックアップスケジュールを設定する際に、[バックアップストレージタイプ] パラメータを [ユーザー向け OSS] に設定し、独自の Object Storage Service（OSS）バケットをバックアップストレージとして指定しました。ただし、データディザスタリカバリは OSS にアクセスする権限がありません。
内部エラーが発生しました。

解決策：

バックアップスケジュールの [タスクの設定] ページで、組み込みストレージまたは独自の OSS バケットがバックアップスケジュールのバックアップストレージとして使用されているかどうかを確認します。独自の OSS バケットが使用されている場合は、OSS コンソールにログインし、データディザスタリカバリコンソールに表示されているバケットが存在するかどうか、およびデータディザスタリカバリにバケットへのアクセス権限があるかどうかを確認します。詳細については、「DBS をアクティブにするにはどうすればよいですか？」をご参照ください。
OSS バケットが存在し、データディザスタリカバリに OSS へのアクセス権限がある場合は、内部サービスエラーが発生している可能性があります。DingTalk グループのテクニカルサポートにお問い合わせください。

ソースデータベースでバイナリロギング機能が有効になっているかどうかの確認に失敗しました

シナリオ：データディザスタリカバリは、ソースデータベースでバイナリロギング機能が有効になっているかどうかの確認に失敗します。

解決策：このチェック項目は、ソースデータベースでバイナリロギング機能が有効になっているかどうかを確認するために使用されます。チェックが失敗した場合、ソースデータベースのバイナリロギング機能は無効になっています。問題を解決するには、次の手順を実行します。

自己管理 MySQL データベースが存在するサーバーにログインします。

次のコマンドを実行して、自己管理 MySQL データベースの my.cnf 設定ファイルを変更します。

log_bin=mysql_bin
binlog_format=row
server_id=2 // サーバー ID は 1 より大きい整数です。この例の値は参照用です。
binlog_row_image=FULL // ソースデータベースのバージョンが MySQL 5.6 以降の場合は、このパラメータが必要です。

説明

my.cnf 設定ファイルのデフォルトパスは /etc/my.cnf です。実際のパスは異なる場合があります。

次のコマンドを実行して MySQL データベースを再起動します。
```
[$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
[$Mysql_Dir]/bin/safe_mysqld &
```
説明
[$Mysql_Dir] を MySQL データベースのインストールディレクトリに置き換えます。
自己管理 MySQL データベースにログインし、次の SQL 文を実行してバイナリロギング機能が有効になっているかどうかを確認します。
```
SHOW variables LIKE '%log_bin%';
```
次のような情報が表示された場合、バイナリロギング機能は有効になっています。
データディザスタリカバリコンソールで事前チェックを再度実行します。

ソースデータベースのバイナリログ形式の確認に失敗しました

シナリオ：データディザスタリカバリは、ソースデータベースのバイナリログ形式の確認に失敗します。

解決策：このチェック項目は、ソースデータベースのバイナリログ形式が ROW に設定されているかどうかを確認するために使用されます。チェックが失敗した場合、ソースデータベースのバイナリログ形式は ROW に設定されていません。問題を解決するには、次の手順を実行します。

自己管理 MySQL データベースが存在するサーバーにログインします。

my.cnf 設定ファイルを次のように変更します。binlog_format パラメータを ROW に設定します。

log_bin=mysql_bin
binlog_format=ROW  // バイナリログ形式を ROW に設定します。
server_id=2 // サーバー ID は 1 より大きい整数です。この例の値は参照用です。
binlog_row_image=FULL // ソースデータベースのバージョンが MySQL 5.6 以降の場合は、このパラメータが必要です。

説明

my.cnf 設定ファイルのデフォルトパスは /etc/my.cnf です。実際のパスは異なる場合があります。

次のコマンドを実行して MySQL データベースを再起動します。
```
[$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
[$Mysql_Dir]/bin/safe_mysqld &
```
説明
[$Mysql_Dir] を MySQL データベースのインストールディレクトリに置き換えます。
自己管理 MySQL データベースにログインし、次の SQL 文を実行してバイナリログ形式が ROW に設定されているかどうかを確認します。
```
SHOW variables LIKE "%binlog_format%";
```
次のような情報が表示された場合、バイナリログ形式は ROW に設定されています。
データディザスタリカバリコンソールで事前チェックを再度実行します。

ソースデータベースの binlog_row_image パラメータが FULL に設定されているかどうかの確認に失敗しました

シナリオ：データディザスタリカバリは、ソースデータベースの binlog_row_image パラメータが FULL に設定されているかどうかの確認に失敗します。

解決策：このチェック項目は、MySQL 5.6 以降のデータベースにのみ適用されます。このチェック項目は、ソースデータベースの binlog_row_image パラメータが FULL に設定されているかどうかを確認するために使用されます。チェックが失敗した場合、ソースデータベースの binlog_row_image パラメータは FULL に設定されていません。その結果、ソースデータベースのバイナリログファイルには完全なイメージが記録されません。問題を解決するには、次の手順を実行します。

自己管理 MySQL データベースが存在するサーバーにログインします。

my.cnf 設定ファイルを次のように変更します。binlog_row_image パラメータを FULL に設定します。

log_bin=mysql_bin
binlog_format=ROW  // バイナリログ形式を ROW に設定します。
server_id=2 // サーバー ID は 1 より大きい整数です。この例の値は参照用です。
binlog_row_image=FULL // ソースデータベースのバージョンが MySQL 5.6 以降の場合は、このパラメータが必要です。

説明

my.cnf 設定ファイルのデフォルトパスは /etc/my.cnf です。実際のパスは異なる場合があります。

次のコマンドを実行して MySQL データベースを再起動します。
```
[$Mysql_Dir]/bin/mysqladmin -u root -p shutdown
[$Mysql_Dir]/bin/safe_mysqld &
```
説明
[$Mysql_Dir] を MySQL データベースのインストールディレクトリに置き換えます。
自己管理 MySQL データベースにログインし、次の SQL 文を実行して binlog_row_image パラメータが FULL に設定されているかどうかを確認します。
```
show variables like "%binlog_row_image%";
```
データディザスタリカバリコンソールで事前チェックを再度実行します。

ソースデータベースのサーバー ID の確認に失敗しました

シナリオ：データディザスタリカバリは、ソースデータベースのサーバー ID の確認に失敗します。

解決策：MySQL データベースの増分データ移行タスクが開始される前に、データディザスタリカバリはソースデータベースの server_id パラメータの値を確認します。データディザスタリカバリが自己管理 MySQL データベースの server_id パラメータの値の確認に失敗した場合は、次の手順を実行して問題を解決します。

自己管理 MySQL データベースサーバーにログインし、次の SQL 文を実行して server_id パラメータの値を表示します。
```
SHOW variables LIKE '%server_id%';
```
次の SQL 文を実行して server_id パラメータの値を変更します。server_id パラメータの値は、1 より大きい整数に設定する必要があります。
```
SET global server_id=[$ID];
```
説明
- [$ID] を 1 より大きい整数に置き換えます。入力した値が別のデータベースで使用されていないことを確認してください。
- 自己管理データベースがプライマリ/セカンダリモードでデプロイされている場合は、プライマリ - セカンダリレプリケーションに影響がないことを確認してください。
- 上記ステートメントを実行した後、設定ファイルの server_id パラメータの値を変更する必要があります。そうしないと、データベースの再起動後に server_id パラメータに指定した値が無効になります。
データディザスタリカバリコンソールで事前チェックを再度実行します。

ソースデータベースにバイナリログファイルが存在するかの確認に失敗しました

シナリオ：自己管理 MySQL データベースのバックアップスケジュールを開始する際に、データディザスタリカバリはソースデータベースにバイナリログファイルが存在するかの確認に失敗します。

解決策：

MySQL CLI で次のコマンドを実行して、バイナリロギング機能が有効になっているかどうかを確認します。
```
SHOW variables LIKE 'log_%';
```

バイナリロギング機能が無効になっている場合は、有効にします。次のコマンド出力は、バイナリロギング機能が無効になっていることを示しています。この場合、my.cnf 設定ファイルを変更して機能を有効にする必要があります。Linux サーバーでは、Vim コマンドを実行して設定ファイルを編集できます。

off

# /etc/my.cnf ディレクトリに移動します。
vim /etc/my.cnf

# I キーを押して編集モードに入ります。
# log_bin パラメータを mysql_bin に設定し、その他のパラメータを指定します。
log_bin = mysql_bin
binlog_format = row
server_id = 2
expire_logs_days = 30

# ESC キーを押して編集モードを終了し、:wq と入力してファイルを保存します。

次のコマンドを実行して、自己管理 MySQL データベースを再起動します。
```
systemctl restart mysqld
```
説明
設定ファイルへの変更は、データベースを再起動した後に有効になります。ピーク時以外の時間にデータベースを再起動することをお勧めします。
データベースを再起動した後、手順 1 のコマンドを実行して、バイナリロギング機能が有効になっているかどうかを確認します。有効になっている場合は、バックアップスケジュールを再起動します。

ストレージエンジンの確認に失敗しました

解決策：このチェック項目は、ソースデータベースのストレージエンジンが増分データ移行をサポートしているかどうかを確認するために使用されます。FEDERATED および MRG_MYISAM ストレージエンジンは、MySQL データベース間の増分データ移行をサポートしていません。チェックが失敗した場合、ソースデータベース内のテーブルが上記のストレージエンジンのいずれかを使用している可能性があります。問題を解決するには、次の操作を実行します。

バックアップスケジュールの [タスクの設定] ページで、[バックアップオブジェクトの編集] をクリックします。増分データ移行をサポートしていないストレージエンジンを使用しているテーブルをバックアップオブジェクトから削除します。

説明

変更が有効になると、システムはすぐにデータをバックアップします。これはソースデータベースとビジネスに影響を与える可能性があります。ピーク時以外の時間に設定を変更することをお勧めします。

MySQL データベースのパスワード形式の確認に失敗しました

解決策：データディザスタリカバリは、MySQL データベースが以前のバージョンのパスワード形式を使用しているかどうかを確認します。詳細については、「old_passwords」をご参照ください。

オブジェクト名の競合

シナリオ：選択したリストアオブジェクトが、ターゲットデータベース内の既存のオブジェクトと同じ名前を使用しています。

解決策：別のリストアタスクを作成し、[同名のオブジェクトの名前を変更する] を選択するか、[編集] をクリックして、ターゲットデータベースにリストアするオブジェクトの名前を変更します。失敗したリストアタスクは削除できます。

高度なダウンロード機能で返される可能性のある一般的なエラーコード

シナリオ：ApsaraDB RDS コンソールの バックアップと復元 ページで、[インスタンスバックアップファイルのダウンロード] が選択不可になっています。

DBS-DownloadTask.Region

原因：高度なダウンロード機能は、現在のリージョンでは使用できません。

解決策：DingTalk グループ（ID 35585947）のテクニカルサポートにお問い合わせください。

DBS-DownloadTask.InstanceInfo

原因：ApsaraDB RDS インスタンスに関する情報の取得に失敗しました。

解決策：ApsaraDB RDS インスタンスが異常かどうか、またはインスタンスが削除されているかどうかを確認します。

DBS-DownloadTask.DbType

原因：ApsaraDB RDS インスタンスのデータベースエンジンは、高度なダウンロード機能をサポートしていません。

解決策：ApsaraDB RDS インスタンスのデータベースエンジンが MySQL または PostgreSQL であることを確認してください。この機能は、他のタイプの ApsaraDB RDS インスタンスではサポートされていません。

DBS-DownloadTask.CustinId

原因：ApsaraDB RDS インスタンスでは高度なダウンロード機能を使用できません。

解決策：しばらくお待ちください。高度なダウンロード機能は段階的に提供されています。DingTalk グループ（ID 35585947）のテクニカルサポートにお問い合わせいただけます。

DBS-DownloadTask.CustinName

原因：ApsaraDB RDS インスタンスでは高度なダウンロード機能を使用できません。

DBS-DownloadTask.user

原因：ApsaraDB RDS インスタンスでは高度なダウンロード機能を使用できません。

DBS-DownloadTask.Instance.Version

原因：ApsaraDB RDS インスタンスのマイナーエンジンバージョンが、高度なダウンロードタスクを作成するための前提条件を満たしていません。

解決策：ApsaraDB RDS インスタンスのマイナーエンジンバージョンは 20201031 以降である必要があります。ApsaraDB RDS インスタンスのマイナーエンジンバージョンを更新する方法の詳細については、「マイナーエンジンバージョンの更新」をご参照ください。更新中に問題が発生した場合は、ApsaraDB RDS ユーザーのテクニカルサポートにお問い合わせください。

説明

詳細については、「バックアップファイルのダウンロード」をご参照ください。

DBS-DownloadTask.Instance.Storage.Type

原因：現在のストレージタイプの ApsaraDB RDS インスタンスは、高度なダウンロード機能をサポートしていません。

解決策：標準 SSD または拡張 SSD（ESSD）を使用する ApsaraDB RDS インスタンスのみが、高度なダウンロード機能をサポートしています。ApsaraDB RDS コンソールの 基本情報 ページに移動して、ApsaraDB RDS インスタンスのストレージタイプを確認できます。ストレージタイプ

DBS-DownloadTask.Instance.Param

原因：ApsaraDB RDS インスタンスが正しく設定されていません。

解決策：ApsaraDB RDS インスタンスのマイナーエンジンバージョンが高度なダウンロードタスクを作成するための前提条件を満たしており、バックアップデータが暗号化されていないことを確認してください。詳細については、「バックアップファイルのダウンロード」トピックの「ダウンロード方法」セクションをご参照ください。

DBS-DownloadTask

原因：ApsaraDB RDS インスタンスは高度なダウンロード機能をサポートしていません。

解決策：ApsaraDB RDS インスタンスが、次のトピックで説明されている高度なダウンロード機能の前提条件を満たしていることを確認してください。

ApsaraDB RDS for MySQL：ApsaraDB RDS for MySQL インスタンスのバックアップファイルをダウンロードする
ApsaraDB RDS for PostgreSQL：ApsaraDB RDS for PostgreSQL インスタンスのバックアップファイルをダウンロードする

説明

この機能を使用する前に、高度なダウンロード機能の制限と使用上の注意をよく理解することをお勧めします。

タスクの実行時に返される可能性のある一般的なエラーコード

DBS-000000

シナリオ：ネイティブの物理フルバックアップタスクが失敗します。

原因：データディザスタリカバリは、バックアップスケジュールで使用されているバックアップゲートウェイを使用してデータベースサーバーに接続できず、再試行回数が上限の 100 に達しました。一般的な原因は、バックアップゲートウェイが切断されていることです。

例：

DBS-000000 スケジューリングに失敗しました。タスクは再試行されましたが、最大制限を超えました

解決策：

バックアップスケジュールの [タスクの設定] ページに移動し、バックアップスケジュールで使用されているバックアップゲートウェイが [オフライン] 状態になっているかどうかを確認します。
[バックアップゲートウェイ] ページで、バックアップゲートウェイの IP アドレス、ホスト名、最後のハートビート時間が異常かどうかを確認します。
バックアップゲートウェイがインストールされているサーバーの状態とネットワーク設定を確認します。
サーバーが正常に動作していてネットワークが接続されている場合は、バックアップゲートウェイの再起動を試みることができます。以前のバージョンのバックアップゲートウェイには脆弱性がある可能性があります。バックアップゲートウェイを最新バージョンにアップグレードします。詳細については、「バックアップゲートウェイのインストール」をご参照ください。
説明
上記の手順を実行してもバックアップゲートウェイを起動できない場合は、DingTalk グループのテクニカルサポートにお問い合わせください。

DBS-000001

シナリオ：論理フルバックアップタスクが失敗します。

原因：タスクが失敗し、再試行回数が上限に達しました。

例：

DBS-000001 スケジューリングに失敗しました。タスクは再試行されましたが、最大制限を超えました、または 7 時間以上ハングしました

解決策：タスクを再起動して、タスクの状態を確認します。エラーが解決しない場合は、DingTalk グループのテクニカルサポートにお問い合わせください。

DBS-000002

シナリオ：論理スキーマバックアップまたはフルバックアップタスクが失敗します。

原因：使用可能なサービスリソースがありません。

例：

DBS-000002 現在のシステムに使用可能なリソースがないため、スケジューリングがタイムアウトしました...

解決策：DingTalk グループのテクニカルサポートにお問い合わせください。

DBS-000003

シナリオ：タスクが失敗します。

原因：タスクが無効です。

例：

DBS-000003 このタスクのインスタンスが見つかりませんでした

解決策：DingTalk グループのテクニカルサポートにお問い合わせください。

DBS-000004

シナリオ：物理バックアップまたはリストアタスクが失敗します。

原因：タスクの開始時に、物理バックアップまたはリストアタスクのスケジューリングに失敗しました。

例：

DBS-000004 + [エラーメッセージ]

解決策：タスクを再起動してみてください。問題が解決しない場合は、DingTalk グループのテクニカルサポートにお問い合わせください。

DBS-000005

シナリオ：論理バックアップまたはリストアタスクが失敗します。

原因：論理バックアップまたはリストアタスクが開始時に異常にスケジュールされています。

例：

DBS-000005 + [エラーメッセージ]

解決策：異常なタスクを再起動してみてください。問題が解決しない場合は、DingTalk グループのテクニカルサポートにお問い合わせください。

DBS-000006

シナリオ：物理バックアップまたはリストアタスクの開始時にタイムアウトが発生します。

原因：物理バックアップまたはリストアタスクが開始時に異常にスケジュールされているか、リソースが異常です。

例：

DBS-000006 + [エラーメッセージ]

解決策：異常なタスクを再起動してみてください。問題が解決しない場合は、DingTalk グループのテクニカルサポートにお問い合わせください。

DBS-000007

シナリオ：論理バックアップまたはリストアタスクの開始時にタイムアウトが発生します。

原因：論理バックアップまたはリストアタスクが開始時に異常にスケジュールされているか、リソースが異常です。

例：

DBS-000007 + [エラーメッセージ]

解決策：異常なタスクを再起動してみてください。問題が解決しない場合は、DingTalk グループのテクニカルサポートにお問い合わせください。

DBS-002003

シナリオ：SQL Server データベースのネイティブ物理バックアップがフルバックアップモードで実行されているときにエラーが発生します。

原因：データベースにアクセスできません。データベースに対する権限がないか、データベースが存在しないか、データベースにアクセスできない可能性があります。

例：

DBS-002003、メッセージ：ユーザーにはデータベース 'UFTData305999_000002' を変更する権限がありません。データベースが存在しないか、アクセスチェックを許可する状態ではありません。
DBS-002003、メッセージ：ユーザーにはデータベース 'UFDATA' を変更する権限がありません
DBS-002003、メッセージ：ユーザー 'guest' には DBCC LOGIN を実行する権限がありません
DBS-002003 ["ホスト localhost、ポート 1433 への TCP/IP 接続に失敗しました。エラー："接続が拒否されました：接続します。接続プロパティを確認し、SQL Server のインスタンスがホスト上で実行されていて、ポートで TCP/IP 接続を受け入れていること、およびファイアウォールがポートへの TCP 接続をブロックしていないことを確認してください。"]

解決策：

データベースがオフラインかどうかを確認します。データベースがオンラインであることを確認します。
データベースがリストアされている場合は、データベースがリストアされるまで待ってから、別のタスクを再起動します。

接続が暗号化されているかどうかを確認します。

SELECT encrypt_option FROM sys.dm_exec_connections WHERE session_id = @@SPID

レジストリを表示して、トランスポート層セキュリティ（TLS）暗号化が有効になっているかどうかを確認します。
```
HKey_Local_Machine\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.x\Server
## 1.x は TLS のバージョンを示します。例：1.0、1.1、1.2。
```
関連する設定項目が存在し、その値が 1 の場合、TLS 暗号化は有効になっています。TLS 暗号化を無効にするには、次の手順を実行します。
1. 設定項目の値を 1 から 0 に変更します。
2. Windows で、[スタート] 検索ボックスに [インターネットオプション] と入力して検索します。[インターネットのプロパティ] ダイアログボックスで、[詳細設定] タブをクリックし、TLS に関連するチェックボックスをオフにします。
3. コンピュータを再起動し、バックアップタスクを再起動します。

DBS-002009

シナリオ：スキーマバックアップが失敗します。

原因：

データベースアカウント名またはパスワードが無効です。
データベースアカウントの権限が変更されたか、データベースがデータディザスタリカバリの IP アドレスからのアクセスを拒否しています。
データベースがデプロイされているサーバーのファイアウォールルールが変更されています。
データディザスタリカバリのネットワーク接続が異常です。たとえば、ネットワークマッピングが変更されています。

例：

DBS-002009 com.alibaba.dts.exception.message.LocalException: DBS-002009 Connect db jdbc:mysql://*:*?useSSL=false timeout.

解決策：詳細については、このトピックの「ソースデータベースへの接続テストに失敗しました」セクションをご参照ください。まず、接続エラーがデータベースアカウント名またはパスワードの変更、データベースアカウントの権限、データディザスタリカバリの IP アドレス、またはファイアウォールルールによって発生しているかどうかを確認します。上記の項目が変更されていない場合は、ネットワークマッピングを確認して再生成します。

バックアップスケジュールの [タスクの設定] ページに移動し、[バックアップオブジェクトの編集] をクリックします。
データベースアカウント名とパスワードを再入力し、[接続テスト] をクリックします。
接続テスト中に、システムはバックグラウンドでビジネス要件に基づいてネットワークマッピングを確認し、再生成します。
説明
ソースデータベースが想定どおりに設定されているにもかかわらず接続テストが引き続き失敗する場合は、DingTalk グループのテクニカルサポートにお問い合わせください。
テストに合格したら、[次へ] をクリックします。
バックアップするデータベースとテーブルを選択し、[保存] をクリックして設定をバックアップスケジュールに保存します。
[保存] をクリックすると、上記の設定が有効になり、データディザスタリカバリはすぐにバックアップを開始します。バックアップはソースデータベースとビジネスに影響を与えます。ピーク時以外の時間に設定を変更して保存することをお勧めします。

DBS-102001

シナリオ：タスクの実行時にエラーが発生します。

原因：バックアップタスクの完了後、バックアップオブジェクトがメタデータベースに報告されるときにエラーが返されます。これは、スキーマバックアップで発生する一般的なエラーです。タスクを再起動してエラーをトラブルシューティングできます。

例：

DBS-102001 java.lang.IllegalStateException: RecordSplit は FAILED または SUCCE である必要があります

解決策：タスクを再起動してみてください。問題が解決しない場合は、DingTalk グループのテクニカルサポートにお問い合わせください。

DBS-105001

シナリオ：タスクの実行時にエラーが発生します。

原因：ハートビートがメタデータベースに報告されるときにタイムアウトが発生します。

例：

DBS-105001 com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: データベースサーバーへの接続を作成できませんでした。3 回再接続を試みました。諦めます。
com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: 接続が多すぎます

解決策：タスクを再起動してみてください。問題が解決しない場合は、DingTalk グループのテクニカルサポートにお問い合わせください。

DBS-106001

シナリオ：タスクの実行時にエラーが発生します。

原因：OSS 内部エラーが発生します。

例：

DBS-106001 java.lang.RuntimeException: com.taobao.amp.error.RequestError: ご連絡ください...
DBS-106001 エラータスク数 2 が最大制限に達しました。

解決策：DingTalk グループのテクニカルサポートにお問い合わせください。

DBS-202002

シナリオ：OSS バケットにデータをバックアップするタスクの実行時にエラーが発生します。

原因：OSS サービスの支払いが延滞しています。

例：

DBS-202002 java.io.IOException: com.taobao.amp.error.RequestError: UserDisable

解決策：

バックアップスケジュールの [タスクの設定] ページで、独自の OSS バケットがバックアップスケジュールのバックアップストレージとして使用されているかどうかを確認します。独自の OSS バケットが使用されている場合は、OSS サービスの支払いの延滞を確認し、OSS サービスを更新してから、バックアップタスクを再試行します。
OSS バケットを使用していない場合は、DingTalk グループのテクニカルサポートにお問い合わせください。

DBS-203101

シナリオ：SQL Server データベースのネイティブ物理バックアップがフルバックアップモードで実行されているときにエラーが発生します。

原因：

データベースが動作しなくなりました。
データベースで SSL 暗号化が有効になっています。

例：

DBS-203101 データベース接続エラー

解決策：

SQL Server Management Studio（SSMS）を使用して、データベースのポート番号を使用して SQL Server データベースにログインします。データベースが存在するか、実行されているかを確認します。
デフォルトでは、ポート番号を使用せずにデータベースにログインできます。たとえば、localhost,1433 はカンマ（,）で区切られます。
説明
データディザスタリカバリは、データベースへの TCP 接続のみをサポートしています。
現在のデータベースで SSL 暗号化が無効になっていることを確認します。

DBS-203102

シナリオ：SQL Server データベースのネイティブ物理バックアップがフルバックアップモードで実行されているときにエラーが発生します。

原因：

データベースが削除されました。
データベースの名前が変更されました。
データベースが異常な状態にあり、バックアップできません。

例：

DBS-203102 データベースが見つかりませんでした ......

解決策：

データベースが削除されているかどうかを確認します。データベースが削除されている場合は、バックアップオブジェクトを再設定します。
バックアップスケジュールの [タスクの設定] ページに移動し、[バックアップオブジェクトの編集] をクリックして、バックアップオブジェクトを設定します。
説明
再設定されたバックアップオブジェクトが保存されて有効になると、すぐにバックアップが開始されます。ビジネスとソースデータベースへの影響に注意してください。
データベースの名前が変更されているかどうかを確認します。データベースの名前が変更されている場合は、前の手順を参照してバックアップオブジェクトを再設定します。
データベースがオフラインかどうかを確認します。データベースがオンラインであることを確認します。
データベースがリストアされている場合は、データベースがリストアされるまで待ってから、別のタスクを再起動します。
データベースの自動クローズ機能が有効になっている場合は、自動クローズ機能を False に設定します。

DBS-203103

シナリオ：SQL Server データベースのネイティブ物理バックアップがフルバックアップモードで実行されているときにエラーが発生します。

原因：データベースが使用できません。

例：

DBS-203103 データベースサーバーはすでにシャットダウンされています

解決策：データベースを使用可能にします。

DBS-203104

シナリオ：SQL Server データベースのネイティブ物理バックアップがフルバックアップモードで実行されているときにエラーが発生します。

原因：仮想デスクトップインフラストラクチャ（VDI）コンポーネントで問題が発生しました。

例：

DBS-203104 VDI の待機が 30 秒でタイムアウトしました

解決策：Windows イベントを確認して VDI コンポーネントの問題をトラブルシューティングし、問題が解決したらタスクを再起動することをお勧めします。チェックで例外が見つからない場合は、しばらく待ってからバックアップを再試行できます。エラーが解決しない場合は、DingTalk グループのテクニカルサポートにお問い合わせください。

DBS-203201

シナリオ：SQL Server データベースのネイティブ物理バックアップがフルバックアップモードで実行されているときにエラーが発生します。

原因：

原因：複数のバックアップタスクが同時にデータベースをバックアップするために実行されています。
これはログの切り捨てによって発生します。ログの切り捨ての考えられる原因は次のとおりです。
- 他のバックアップツールがユーザー側でデータベースをバックアップしており、ログの切り捨てが発生しています。
- ユーザーがデータベースを縮小しており、ログの切り捨てが発生しています。
- ユーザーがデータベースの復旧モデルを調整しました。
- ログの切り捨てを引き起こす可能性のあるその他の動作。

例：

DBS-203201 データベース xxx バックアップ可能 lsn {1} が制限 {2} を超えました

データベース XXXXXX バックアップ可能 lsn 10000000000000000009 が制限 10000000000000000001 を超えました、すでに増分バックアップ名：、バックアップ日時：2024-01-19 00:00:00

解決策：

原因：複数のバックアップタスクが同時にデータベースをバックアップするために実行されています。
- 複数のバックアップタスクが同時にデータベースをバックアップするために実行されている場合は、一度に 1 つのバックアップタスクのみを保持し、他のバックアップタスクを一時停止します。
- スクリプトを使用してスケジュールに基づいてデータベースをバックアップする場合は、他のバックアップタスクを一時停止して、一度に 1 つのバックアップタスクのみがデータベースをバックアップするようにします。
- 複数のデータベースの増分バックアップを実行する場合、一部のデータベースのバックアップに失敗する可能性があります。この場合、増分バックアップを無効にしてから、増分バックアップを有効にします。
これはログの切り捨てによって発生します。
- ログが切り捨てられているため、バックアップは不完全です。コンソールでフルバックアップを再開することをお勧めします。

DBS-203202

シナリオ：SQL Server データベースのネイティブ物理バックアップがフルバックアップモードで実行されているときにエラーが発生します。

原因：

フルバックアップを実行する前に増分バックアップが実行されます。この問題は、初めてバックアップタスクを設定するときに発生する可能性があります。
この問題は、バックアップタスクを設定するときに CopyOnly オプションを選択した場合にも発生する可能性があります。

例：

DBS-203202 現在のデータベースバックアップがないため、BACKUP LOG {0} を実行できません

解決策：手動でフルバックアップを実行してから、バックアップタスクの失敗した増分バックアップを再起動できます。

DBS-203203

シナリオ：SQL Server データベースのネイティブ物理バックアップがフルバックアップモードで実行されているときにエラーが発生します。

原因：FULL 復旧モデルを使用していないため、トランザクションログをバックアップできません。

例：

DBS-203203 FULL MODE でのみ増分トランザクションログバックアップがサポートされています。データベース {0}

解決策：次の SQL 文を実行して、復旧モデルを FULL に設定します。

ALTER DATABASE [xxx] SET RECOVERY FULL

DBS-203205

シナリオ：SQL Server データベースのネイティブ物理バックアップがフルバックアップモードで実行されているときにエラーが発生します。

原因：データベースがオフラインです。

例：

DBS-203205 データベースの状態は次のとおりです。DBS-203205 データベース AIS20210425120342 の状態は {1} です

解決策：

データベースがオフラインかどうかを確認します。データベースがオンラインであることを確認します。
データベースがリストアされている場合は、データベースがリストアされるまで待ってから、別のタスクを再起動します。

DBS-203206

シナリオ：SQL Server データベースのネイティブ物理バックアップがフルバックアップモードで実行されているときにエラーが発生します。

原因：データベースにアクセスできません。データベースが破損している可能性があります。データベースが使用可能かどうかを確認する必要があります。

例：

DBS-203206 メッセージ：データベース 'UFTData992044_000002' は、次の理由により開けません

解決策：

データベースがオフラインかどうかを確認します。データベースがオンラインであることを確認します。
データベースがリストアされている場合は、データベースがリストアされるまで待ってから、別のタスクを再起動します。

DBS-203240

シナリオ：SQL Server データベースのネイティブ物理バックアップがフルバックアップモードで実行されているときにエラーが発生します。

原因：現在のデータベースアカウントにシステム管理者の権限がありません。

例：

DBS-203240、メッセージ：ユーザー 'guest' には DBCC LOGIN を実行する権限がありません

解決策：バックアップスケジュール設定を変更します。必要な権限を持つデータベースアカウントを使用するか、使用するデータベースアカウントにシステム管理者ロールを割り当てます。データベースアカウントの変更方法の詳細については、「バックアップソースデータベースを変更するにはどうすればよいですか？」をご参照ください。

DBS-203301

シナリオ：SQL Server データベースのネイティブ物理バックアップがフルリストアモードで実行されているときにエラーが発生します。

原因：テールログがバックアップされていません。データの損失を防ぐには、データベースをリストアする前に、現在のデータベースのテールログをバックアップする必要があります。

説明

テールログは、最後のログバックアップの後に生成されたトランザクションログです。

例：

DBS-203301 データベース {0} のログのテールはバックアップされていません。失いたくない作業がログに含まれている場合は、BACKUP LOG WITH NORECOVERY を使用してログをバックアップします。RESTORE ステートメントの WITH REPLACE 句または WITH STOPAT 句を使用して、ログの内容を上書きします

解決策：

次のコマンドを実行してテールログをバックアップします。

BACKUP LOG [リストアするデータベースの名前] TO DISK='C:\backupdir\moyun_test.trn' WITH NORECOVERY;

失敗したフルリストアタスクを再起動します。

DBS-203302

シナリオ：SQL Server データベースのネイティブ物理バックアップがフルバックアップモードで実行されているときにエラーが発生します。

原因：現在のフルバックアップセットの最後のトランザクションログ LSN {0} が、別のフルバックアップセットのトランザクションログ LSN {1} より前に生成されているため、フルバックアップセットを使用してデータをリストアできません。

例：

DBS-203302 このバックアップセットのログは LSN {0} で終了します。これはデータベースに適用するには早すぎます。LSN {1} を含む最新のログバックアップをリストアできます

解決策：DingTalk グループのテクニカルサポートにお問い合わせください。

DBS-301005

シナリオ：Oracle データベースの物理バックアップがフルバックアップモードで実行されているときにエラーが発生します。

原因：Oracle データベースの ARCHIVELOG モードが無効になっています。最初に Oracle データベースの ARCHIVELOG モードを有効にする必要があります。

例：

DBS-301005、メッセージ：INNER_ERROR[301005]: データベースはアーカイブモードではありません
DBS-301005、メッセージ：INNER_ERROR[301005]:user="" ConnectString="" スタンドアロ ンパラメータ= ......

解決策：アーカイブモードを有効にします。詳細については、「アーカイブモードを有効にする」をご参照ください。

DBS-301502

シナリオ：MySQL データベースの物理バックアップの実行時にエラーが発生します。

原因：バックアップ中に DDL 操作を REDO ログに記録できません。

例：

DBS-301502、REDO ログなし

解決策：DDL 操作が実行されていないときにバックアップタスクを再起動します。

DBS-301503

シナリオ：MySQL データベースの物理バックアップの実行時にエラーが発生します。

原因：REDO ログの生成速度がバックアップ速度を超えています。

例：

DBS-301503、ログのコピーが遅すぎます

解決策：REDO ファイルの容量を増やし、ピーク時以外の時間にバックアップを実行することをお勧めします。

DBS-301504

シナリオ：MySQL データベースの物理バックアップの実行時にエラーが発生します。

原因：MySQL データベースのテーブルで暗号化が有効になっています。データディザスタリカバリは、暗号化されたテーブルのバックアップをサポートしていません。

例：

DBS-301504、暗号化がありません

解決策：テーブルの暗号化機能を無効にして、バックアップタスクを再起動することをお勧めします。暗号化機能を無効にしたくないが、データディザスタリカバリの使用を停止したい場合は、データディザスタリカバリのカスタマーサービススタッフに連絡して理由を説明し、バックアップスケジュールの払い戻しを申請してください。

DBS-301505

シナリオ：MySQL データベースの物理バックアップの実行時にエラーが発生します。

原因：バックアッププロセスがシステムによって終了されました。

例：

DBS-301505、シグナル：終了しました

解決策：タスクを再起動します。

DBS-302035

シナリオ：Oracle データベースの物理バックアップがフルバックアップモードで実行されているときにエラーが発生します。

原因：Oracle インスタンスのデータベースロール情報を取得できません。

例：

DBS-302035 USER_CAN_NOT_LOAD_INSTANCE_ROLE[302035]

解決策：

データベースインスタンスがデプロイされているサーバーにログインします。
次のコマンドを実行して、システム管理者としてデータベースにログインします。
```
sqlplus / as sysdba
```
次の SQL 文を実行して、結果が返されるかどうかを確認します。
```
select database_role from v$database;
```
結果が返されない場合は、エラーをトラブルシューティングします。結果が返される場合は、DingTalk グループのテクニカルサポートにお問い合わせください。

DBS-400001

シナリオ：ネイティブ物理バックアップがフルバックアップモードで実行され、バックアップデータが変換されるときにエラーが発生します。

原因：バックアップスケジュールの仕様がビジネス要件を満たしていません。

例：

DBS-400001、メッセージ：Java ヒープスペース。
DBS-400001 java.lang.OutOfMemoryError: Java ヒープスペース

解決策：バックアップスケジュールの仕様をアップグレードすることをお勧めします。リストアタスクなどの緊急タスクのメモリ制限を一時的に増やす必要がある場合は、DingTalk グループのテクニカルサポートにお問い合わせください。バックアップスケジュールの仕様をアップグレードする方法の詳細については、「バックアップスケジュールのアップグレード」をご参照ください。

DBS-999999 またはエラーコードなし

シナリオ：タスクの実行時にエラーが発生します。

原因：例外がデータディザスタリカバリによって定義されていないか、例外のエラーコードが定義されていますが、エラーコードが表示されていません。

例：

DBS-999999 + [エラーメッセージ]

解決策：エラーメッセージをコピーして、このトピックでエラーを検索し、問題が別のエラーコードを使用して定義されているかどうかを確認することをお勧めします。このトピックに関連するエラーが見つからない場合は、DingTalk グループのテクニカルサポートにお問い合わせください。