Data Transmission Service:一般的なエラーコードとトラブルシューティング方法

DTS-31009: データの処理中 (recordRange: 5799806987638145024) に失敗しました原因: CriticalAnyAllException: capture-dstore: DTS-51009: dstoreからレコードをフェッチできませんでしたTimeoutException: 120000ミリ秒以内にオフセットを取得できませんでした

• 原因: データ書き込みモジュールとデータキャッシュモジュール間の接続がネットワークのジッターによりタイムアウトします。
• 解決策: タスクを再起動して、タスクを再開できるかどうかを確認します。

• 原因1: タスクが長期間一時停止されます。 タスクが再起動された後、データキャッシュモジュールには、2021-5-20 21:17:51などの指定された時点でデータがありません。
  説明 エラーメッセージに表示される時刻は、UNIXタイムスタンプです。 検索エンジンを使用して、UNIXタイムスタンプコンバーターを取得し、UNIXタイムスタンプをUTC時刻に変換できます。

  解決策1: 指定された時点が、バイナリログやredoログなど、ソースデータベースの増分データ解析に使用されるログの時間範囲に含まれているかどうかを確認します。 期間内に含まれる場合は、Alibaba Cloudテクニカルサポートに連絡してデータを再読み込みしてください。 そうでない場合は、別のタスクを作成する必要があります。

  解決策2: 別のタスクを作成します。 タスクを実行した後、タスクを長期間一時停止しないでください。 タスクが6時間以上一時停止されると、タスクを開始できなくなります。

• 原因2: タスクが長期間失敗しました。 障害を修正した後、データキャッシュモジュールには指定された時点でデータがありません。

  解決策: 別のタスクを作成します。 タスクの実行中にエラーが発生した場合は、エラーを修正してできるだけ早くタスクを再開し、タスクが長期間失敗しないようにします。

• 原因3: 完全なデータ移行または同期中、DTSは、ソースデータベースの過去24時間のデータログまたは増分データ解析用の50 GBのデータログを循環的に保存します。 完全なデータ移行または同期が長期間続く場合、DTSはタスクの開始後にキャッシュされたデータログをクリアしている可能性があります。 その結果、増分データの解析に使用されるデータログは不完全です。

  解決策: 別のタスクを作成します。 タスクを作成する前に、移行または同期するデータの量を評価します。 データ量が多い場合は、複数のタスクを作成することを推奨します。

DTS-30019: ターゲットテーブルdb_name.table_nameに列 [column_in_source<-->column_in_target] が見つかりません

DTS-70019: ターゲットテーブルdb_name.table_nameに列 [column_in_source<-->column_in_target] が見つかりません

• 考えられる原因:
  • 原因1: データ移行タスクを設定するときに、移行タイプとしてスキーマ移行を選択しません。 その結果、ソースデータベースとターゲットデータベースのテーブルのスキーマに一貫性がありません。
  • 原因2: タスクの設定後、ソースデータベースまたはターゲットデータベースでDDLステートメントを実行して、テーブルスキーマを変更します。 その結果、ソースデータベースとターゲットデータベースのテーブルのスキーマに一貫性がありません。
• 解決策: ソースデータベースとターゲットデータベースのテーブルのスキーマを変更し、スキーマが一貫していることを確認します。

• 考えられる原因: データベースアカウントにCREATE TABLE権限がありません。
• 解決策: データベースアカウントにCREATE TABLE権限を付与します。

• 考えられる原因: DTSは、同期シナリオでDDLステートメントをサポートしていません。 その結果、DDL文の実行に失敗します。
• ソリューション:
  • データベース全体を同期する必要がない場合は、テーブルを再度同期することをお勧めします。 選択したオブジェクトからテーブルを削除し、ターゲットデータベースのテーブルを削除してから、選択したオブジェクトにテーブルを再度追加できます。 DTSは、スキーマと履歴データを再度同期します。 このようにして、サポートされていないDDLステートメントは無視されます。
  • データベース全体を同期する必要がある場合は、AnalyticDB for MySQLでテーブル (表a) を作成することを推奨します。 テーブルAは、エラーをトリガーしたテーブル (テーブルB) とは異なる名前でなければなりません。 テーブルAは、ソーステーブルと同じスキーマを持つ必要があります。 INSERT INTO SELECT文を実行してソーステーブルのデータをテーブルAに書き込み、テーブルBを削除し、RENAME文を実行してテーブルAの名前をテーブルBに変更し、データ同期タスクを再起動します。

• 考えられる原因: ターゲットデータベースでシャットダウン操作が実行されます。
• 解決策: ターゲットデータベースが実行されていることを確認します。 次に、データ同期タスクを再起動します。

• 考えられる原因: ネットワークが利用できないか、アカウントに必要な権限がありません。 その結果、MySQLデータベースは、アカウントがリモートログオンを実行することを許可しません。
• ソリューション:
  • ホワイトリストの設定が有効かどうかを確認します。 詳細については、「DTSサーバーのCIDRブロックの追加」をご参照ください。
  • データベースアカウントにリモートログオンを実行する権限があるかどうかを確認します。

• 考えられる原因: 対応するテーブルが存在しません。
• ソリューション:
  • ターゲットデータベースでテーブルが削除されているかどうかを確認します。
  • スキーマの移行中にテーブルが同期されているかどうかを確認します。

• 考えられる原因: データベースの整合性の制約に違反しています。 例えば、NOT NULL列にNULL値が挿入される。
• ソリューション: 1. DMLステートメントに含まれるテーブルスキーマとデータレコードを確認します。 ソーステーブルと宛先テーブルのスキーマが一致していることを確認します。 2. データレコードを見直してから、タスクを再起動します。

• 考えられる原因: ターゲットデータベースのアカウントに必要な権限がありません。
• 解決策: ターゲットデータベースのアカウントにエラーメッセージに記載されている権限があるかどうかを確認します。 そうでない場合は、アカウントに権限を付与し、タスクを再起動します。

• 考えられる原因: スキーマの移行中にエラーが発生しました。 その結果、対応するテーブルは移行先データベースに移行されません。 さらに、ターゲットデータベースのテーブルのスキーマは作成されません。
• 解決策: エラーメッセージに基づいて、データベースまたはテーブルが存在するかどうかを確認します。 そうでない場合は、次の操作を実行します。
  • データ同期タスクの場合、選択したオブジェクトからテーブルを削除し、選択したオブジェクトにテーブルを再度追加して、タスクを再開できるかどうかを確認します。
  • データ移行タスクの場合は、別のタスクを作成します。

• 考えられる原因: ユーザー名またはパスワードが無効です。
• 解決策: 無効なユーザー名とパスワードを入力します。 次に、タスクを再起動します。

• 考えられる原因: ソースデータベースへの接続数が上限に達しました。
• 解決策: ソースデータベースへの接続数の上限を増やします。 次に、タスクを再起動します。

• [例1] DTS-71016: 接続ターゲットに失敗しました (url: jdbc:mysql:// ip_address:port?parameters) 原因: MySQLNonTransientConnectionException: データソース拒否された接続の確立、サーバーからのメッセージ: "Too many connections"
• [例2] DTS-71016: 接続ターゲットに失敗しました (url: jdbc:mysql:// ip_address:port?parameters) 原因: SQLException: null、サーバーからのメッセージ: "Host 'ip_address' は多くの接続エラーのためにブロックされます。

• 考えられる原因:
  • 例1: ターゲットデータベースへの接続数が上限に達しました。
  • 例2: 短期間に同じIPアドレスから過剰な数の失敗したデータベース接続が生成されます。 その結果、新しい接続がブロックされます。
• 解決策:
  • 例1: ターゲットデータベースへの接続数の上限を増やします。 次に、タスクを再起動します。
  • 例2: ターゲットデータベースのエラーを修正します。 たとえば、MAX_CONNECTION_ERRORSパラメーターの値を大きくします。 次に、タスクを再起動します。

• 考えられる原因: 例外が発生したため、Redisサーバーに接続できません。
• 解決策: Redisサーバーのステータスを確認し、サーバーに接続できることを確認します。

• 考えられる原因: ソースデータベース内の2つのテーブルの名前は、TABLEとテーブルなど、大文字と小文字が異なるだけです。 DTSは、競合するテーブル名をサポートしません。
• 解決策: ソースデータベースのテーブル名を確認し、いずれかのテーブル名を変更してから、タスクを再起動します。

• 考えられる原因:
  • 原因1: ディスク容量がいっぱいです。
  • 原因2: テーブルのサイズが上限に達しました。
• ソリューション:
  • 解決策1: ディスクのサイズを変更してから、タスクを再起動します。
  • 解決策2: データベースレベルでテーブルサイズの上限を増やします。 エラーを修正してから、タスクを再起動してください。
    説明 MySQLデータベースの最大テーブルサイズについては、「B.3.2.10 the table is full」をご参照ください。

• 考えられる原因: ターゲットデータベースでロック待機タイムアウトが発生しました。
• 解決策: ターゲットデータベースがMySQLデータベースの場合、次のステートメントを実行して、データベースのロックステータスを確認できます。

  ショー完全なプロセスリスト;
  選択
  * からinnodb_trx; 

  説明 エラーを修正したら、タスクを再起動する必要があります。

• 考えられる原因: ターゲットデータベースが読み取り専用状態です。
• ソリューション:
  • SELECT @ @ read_only; 文を実行して、ターゲットデータベースが読み取り専用状態かどうかを確認します。
  • SET GLOBAL read_only=0; ステートメントを実行して、読み取り専用状態を無効にします。
  説明 読み取り専用状態を無効にした後、タスクを再起動する必要があります。

• 考えられる原因: MySQLデータベースのバイナリログに保存されているスキーマが、DTSに保存されているスキーマと一致していません。 テーブルのスキーマを変更するDDLステートメントがバイナリログに記録されていない場合、スキーマの不整合が発生します。 その結果、DTSはDDLステートメントを解析できず、スキーマを更新しません。 たとえば、SET SESSION sql_log_bin=0文を実行して、テーブルのフィールドタイプをINT(11) からBIGINT(20) に変更します。
• 解決策: DTSに保存されているスキーマをリロードするには、Alibaba Cloudテクニカルサポートにお問い合わせください。