バッチ同期タスクに関する一般的な質問への回答です。
概要
カテゴリ | 関連トピック |
バッチ同期タスクに関する一般的な運用管理上の問題 | |
プラグイン以外のエラー原因と対処法 | |
プラグイン固有のエラー原因と対処法 | |
バッチ同期のシナリオと解決策 |
|
エラーメッセージと対処法 |
|
データソースの接続テストは成功するのに、バッチ同期タスクが失敗するのはなぜですか？
以前に接続テストが成功していた場合は、再度テストを実行して、リソースグループが依然としてデータベースに接続できること（およびデータベース側で変更が行われていないこと）を確認してください。
接続テストに成功したリソースグループが、タスク実行に使用されているものと同じかどうかを確認してください。
タスクが実行されているリソースグループを確認します：
タスクがデフォルトリソースグループで実行されている場合、ログに次のような情報が表示されます：
running in Pipeline[basecommon_ group_xxxxxxxxx]。タスクが Data Integration 用カスタムリソースグループで実行されている場合、ログに次のような情報が表示されます：
running in Pipeline[basecommon_xxxxxxxxx]。タスクが Data Integration 専用リソースグループで実行されている場合、ログに次のような情報が表示されます：
running in Pipeline[basecommon_S_res_group_xxx]。
定期タスクが早朝に時々失敗し、再実行で成功する場合は、エラーが発生した時点のデータベース負荷を確認してください。
Data Integration タスクのリソースグループを切り替えるにはどうすればよいですか？
Data Integration タスクのデバッグに使用するリソースグループは、DataStudio で変更できます。定期的な Data Integration タスクの実行に使用するリソースグループは、オペレーションセンター で変更できます。詳細については、「リソースグループの切り替え」をご参照ください。
ダーティデータのトラブルシューティングと特定方法を教えてください。
ダーティデータの定義：単一のレコードを送信先データソースに書き込む際に例外が発生した場合、そのレコードはダーティデータです。書き込みに失敗したすべてのレコードはダーティデータとして分類されます。
ダーティデータの影響：ダーティデータは送信先に書き込まれません。ダーティデータを許容するかどうかを制御でき、許容されるダーティデータレコードの最大数を指定できます。デフォルトでは、Data Integration はダーティデータを許容します。同期タスクを設定する際に、許容されるダーティデータレコード数を指定できます。詳細については、「ダーティデータルールの設定」をご参照ください。
タスクがダーティデータを許容するように設定されている場合：ダーティデータが生成されてもタスクは継続して実行されますが、ダーティデータは破棄され、送信先に書き込まれません。
タスクが許容されるダーティデータレコード数を制御するように設定されている場合：
許容数が 0 に設定されている場合、ダーティデータが生成されるとタスクは失敗して終了します。
許容数が x に設定されている場合、ダーティデータレコード数が x を超えるとタスクは失敗して終了します。ダーティデータレコード数が x 未満の場合、タスクは継続して実行されますが、ダーティデータは破棄され、送信先に書き込まれません。
ダーティデータのシナリオ分析：
シナリオ 1：
エラーメッセージ：
{"message":"Dirty data encountered when writing to the ODPS destination table: An error occurred in the data of the [3rd] field. Please check the data and make corrections, or you can increase the threshold to ignore this record.","record":[{"byteSize":0,"index":0,"type":"DATE"},{"byteSize":0,"index":1,"type":"DATE"},{"byteSize":1,"index":2,"rawData":0,"type":"LONG"},{"byteSize":0,"index":3,"type":"STRING"},{"byteSize":1,"index":4,"rawData":0,"type":"LONG"},{"byteSize":0,"index":5,"type":"STRING"},{"byteSize":0,"index":6,"type":"STRING"}。解決策：ログにはダーティデータフィールドが表示されており、3 番目のフィールドが異常です。
ダーティデータエラーはライターによって報告されます。ライター側のテーブル作成ステートメントを確認してください。MaxCompute テーブルで指定されたフィールドサイズが、MySQL の対応するフィールドの実際のデータサイズよりも小さい可能性があります。
データ同期の原則：ソースデータソースのデータは送信先データソースに書き込み可能でなければなりません（ソースと送信先のデータ型およびフィールドサイズが一致している必要があります）。具体的には、ソースの VARCHAR データを送信先の INT 列に書き込むことはできません。送信先で定義されたフィールドサイズは、ソースからマッピングされたフィールドの実際のデータサイズを収容できる必要があります。long、varchar、double などの型のソースデータについては、string や text などの広範囲の型を送信先で使用してデータを収容できます。
ダーティデータエラーメッセージが不明瞭な場合は、ログに出力されたダーティデータレコード全体をコピーし、データを調べて送信先のデータ型と比較して、どのフィールドが要件を満たしていないかを特定してください。
例：
{"byteSize":28,"index":25,"rawData":"ohOM71vdGKqXOqtmtriUs5QqJsf4","type":"STRING"}byteSize：バイト数。index：25（26 番目のフィールドを示す）。rawData：具体的な値。type：データ型。
シナリオ 2：
エラーメッセージ：MySQL から null 値を読み取る際に DataX がダーティデータを報告します。
解決策：null 値を含むソースフィールドがマッピングされている送信先フィールドのデータ型を確認してください。データ型が不一致の場合、エラーが報告されます。たとえば、string 型の null 値を int 型の送信先フィールドに書き込むとエラーが発生します。
ダーティデータを確認するにはどうすればよいですか？
バッチ同期中にダーティデータが上限を超えた場合、すべてのデータの同期が失敗しますか？
ダーティデータレコード数が上限を超えると、タスクは直ちに停止します。すでに転送されたレコード数はそのまま維持されます。ダーティデータの上限は、許容されるダーティデータレコードの最大数を指定します。上限が 0 に設定されている場合、最初のダーティデータレコードが検出されるとタスクは停止します。この時点で、一部のレコードがすでに転送されている場合もあれば、データセットの最初のレコードがダーティデータであるため、レコードがまったく転送されていない場合もあります。
長時間実行されるオフライン同期タスクのトラブルシューティング方法を教えてください。
考えられる原因 1：実行に時間がかかりすぎる
データベースで事前 SQL または事後 SQL ステートメント（preSql や postSql など）の実行に時間がかかりすぎ、タスクの実行が遅くなります。
split キーが適切に設定されておらず、タスクの実行が遅くなります。
オフライン同期では、split キー（splitPk）を使用してデータを分割します。Data Integration はこの設定に基づいて同時実行タスクを開始し、同期パフォーマンスを向上させます。（特定のプラグインが split キーを必要とするかどうかは、プラグインドキュメントによります。）
解決策 1：
事前 SQL または事後 SQL ステートメントを設定する場合は、データフィルタリングにインデックスフィールドを使用することを推奨します。
split キーがサポートされている場合は、適切に設定することを推奨します。以下の例は、MySQL Reader プラグインの split キー設定を使用しています：
splitPk 値にはテーブルのプライマリキーを使用することを推奨します。プライマリキーは一般に均等に分散されているため、結果として得られる分割でデータホットスポットを防ぐことができます。
現在、splitPk は整数データの分割のみをサポートしています。文字列、浮動小数点、日付などの型はサポートされていません。サポートされていない型を指定した場合、データは単一チャネルを通じて同期されます。
splitPk を指定しない場合（指定しないか、値を空のままにする場合）、データ同期は単一チャネルを使用してテーブルデータを同期します。
考えられる原因 2：Data Integration タスク実行リソースの待機
解決策 2：ログに長時間 WAIT 状態が表示される場合、現在のタスクを実行している Data Integration 専用リソースグループに、タスクを実行するのに十分な同時実行数がありません。原因と解決策の詳細については、「Data Integration 専用リソースグループの同時実行数不足」をご参照ください。
バッチ同期タスクは、スケジューリングリソースグループによって Data Integration 専用リソースグループにディスパッチされて実行されるため、各バッチ同期タスクはスケジューリングリソースを 1 つ消費します。バッチ同期タスクが長時間実行され、リソースを解放しない場合、他のバッチ同期タスクだけでなく、他の種類の定期タスクもブロックする可能性があります。
エンコードまたは文字化けの問題によるダーティデータエラーを処理するにはどうすればよいですか？
エラー：
データに絵文字が含まれている場合、同期中にダーティデータエラーが発生することがあります：
[13350975-0-0-writer] ERROR StdoutPluginCollector - Dirty data {"exception":"Incorrect string value: '\\xF0\\x9F\\x98\\x82\\xE8\\xA2...' for column 'introduction' at row 1","record":[{"byteSize":8,"index":0,"rawData":9642,"type":"LONG"},}],"type":"writer"}。考えられる原因：
データベースのエンコーディングが utf8mb4 に設定されておらず、絵文字の同期時にエラーが発生します。
ソースデータがすでに文字化けしています。
データベースとクライアントで異なるエンコード形式を使用しています。
ブラウザのエンコーディングが異なり、プレビューが失敗したり文字化けが発生したりします。
解決策：
文字化けの原因に基づいて適切な解決策を選択してください：
ソースデータが文字化けしている場合は、同期タスクを実行する前にまずソースデータを修正してください。
データベースとクライアントで異なるエンコード形式を使用している場合は、まずエンコード形式を変更してください。
ブラウザのエンコーディングがデータベースまたはクライアントのエンコーディングと異なる場合は、まずエンコード形式を統一してからデータをプレビューしてください。
以下の操作を試してみてください：
JDBC 形式で追加されたデータソースの場合は、utf8mb4 を使用するように変更します：
jdbc:mysql://xxx.x.x.x:3306/database?com.mysql.jdbc.faultInjection.serverCharsetIndex=45。インスタンス ID で追加されたデータソースの場合は、データベース名の後に次の形式で追加します：
database?com.mysql.jdbc.faultInjection.serverCharsetIndex=45。データベースのエンコード形式を utf8mb4 に変更します。たとえば、ApsaraDB RDS インスタンスの RDS コンソールでデータベースのエンコード形式を変更できます。
説明RDS データソースのエンコード形式を設定するコマンド：
set names utf8mb4。RDS データベースのエンコード形式を表示するコマンド：show variables like 'char%'。
Task have SSRF attacts エラーを処理するにはどうすればよいですか？
現在、内部データベースネットワークに基づくデータソースは、Data Integration の共有リソースグループを使用してタスクを実行できません。代わりに、Data Integration 専用リソースグループに切り替えてください。詳細については、「Data Integration 専用リソースグループの使用」をご参照ください。
バッチ同期タスクが断続的に成功と失敗を繰り返す
バッチ同期タスクが断続的に失敗する場合、ホワイトリスト構成が不完全であることが原因の可能性があります。データベースのホワイトリストが完全に構成されているかどうかを確認してください。
Data Integration 専用リソースグループを使用する場合：
以前に Data Integration 専用リソースグループの ENI IP アドレスをデータソースのホワイトリストに追加しており、その後リソースグループがスケールアウトされた場合は、スケールアウトされたリソースグループの ENI IP アドレスをデータソースのホワイトリストに迅速に追加して更新する必要があります。
スケールアウトのたびにホワイトリストを更新する必要がないようにするには、Data Integration 専用リソースグループにバインドされた vSwitch の CIDR ブロックをデータベースのホワイトリストエントリとして追加することを推奨します。詳細については、「リソースグループのホワイトリストエントリの追加」をご参照ください。
Data Integration 用共有リソースグループを使用する場合：
Data Integration 用共有リソースグループのリージョンのすべての IP アドレス範囲がデータソースのホワイトリストに追加されていることを確認してください。詳細については、「共有リソースグループのホワイトリストエントリの追加」をご参照ください。
ホワイトリストが正しく構成されている場合は、データベース負荷が高すぎて接続が中断されていないかを確認してください。
オフライン同期のソーステーブルに列を追加（変更）した場合の対処方法を教えてください。
同期タスクの設定ページに移動し、フィールドマッピングを変更して、タスク設定内の変更されたフィールドを更新します。変更を完了したら、変更を有効にするためにタスクを再送信して実行する必要があります。
root ユーザーを使用して MongoDB データソースを追加するとエラーが発生する
root ユーザーを使用して MongoDB データソースを追加するとエラーが発生するのは、同期したいテーブルが存在するデータベース内で作成されたユーザー名を使用する必要があるためです。root ユーザーは使用できません。
たとえば、name テーブルをインポートしたい場合、name テーブルが test データベース内にあるとすると、ここでのデータベース名は test であり、test データベース内で作成されたユーザー名を使用する必要があります。
MongoDB の読み取り時にクエリパラメーターでタイムスタンプを使用して増分同期を実装するにはどうすればよいですか？
代入ノードを使用して、日付型の時刻値をタイムスタンプに変換し、その値を MongoDB データ同期の入力パラメーターとして渡すことができます。詳細については、「MongoDB タイムスタンプフィールドの増分同期を実装する方法」をご参照ください。
MongoDB データを送信先に同期した後に 8 時間のタイムゾーンオフセットが発生する場合の対処方法を教えてください。
cursorTimeoutInMs パラメーターおよび query パラメーターが正しく設定されているかどうかを確認してください。詳細については、「MongoDB Reader の設定」をご参照ください。
MongoDB データ読み取り中にソースで更新されたレコードが送信先に同期されない場合の対処方法を教えてください。
同じクエリ条件で、しばらく時間を置いてからタスクを再起動できます。つまり、構成を変更せずに同期タスクの実行時間を遅らせます。
OSS ファイルの読み取り時にファイル数の制限はありますか？
DataX 自体は OSSReader プラグインに対してファイル数の制限を設けていません。制限は主にタスク用に設定された JVM パラメーターに依存します。ただし、* を object パラメーターとして設定しないことを推奨します。これによりメモリ不足エラーが発生しやすくなるためです。
DataHub への書き込み時に単一書き込みデータ制限を超えて書き込みが失敗する場合の対処方法を教えてください。
エラー：
ERROR JobContainer - Exception when job runcom.alibaba.datax.common.exception.DataXException: Code:[DatahubWriter-04], Description:[Failed to write data.]. - com.aliyun.datahub.exception.DatahubServiceException: Record count 12498 exceed max limit 10000 (Status Code: 413; Error Code: TooLargePayload; Request ID: 20201201004200a945df0bf8e11a42)考えられる原因：
このエラーは、DataX が単一のバッチで DataHub に送信するデータ量が DataHub の制限を超えているために発生します。DataHub に送信されるデータ量に影響を与える主な設定パラメーターは次のとおりです：
Maxcommitsize：DataX が蓄積するバッファーデータを指定します。蓄積されたデータサイズが maxCommitSize 値（MB 単位）に達すると、データがバッチで送信先に送信されます。デフォルト値は 1 MB（1,048,576 バイト）です。
Batchsize：DataX-On-Flume が蓄積するバッファーデータレコード数を指定します。蓄積されたレコード数が batchSize 値に達すると、データがバッチで送信先に送信されます。
解決策：
Maxcommitsize パラメーターおよび Batchsize パラメーターの値を減らしてください。
Lindorm のバルク書き込み方式を使用する場合、毎回既存データが置き換えられますか？
この動作は API 書き込みロジックと一致します。同じ行および列のデータは上書きされますが、他のデータは変更されません。
Elasticsearch インデックスのすべてのフィールドを照会するにはどうすればよいですか？
curl コマンドを使用して Elasticsearch インデックスのマッピングを取得し、マッピングからすべてのフィールドを抽出します。
照会用のシェルコマンド：
//es7 curl -u username:password --request GET 'http://esxxx.elasticsearch.aliyuncs.com:9200/indexname/_mapping' //es6 curl -u username:password --request GET 'http://esxxx.elasticsearch.aliyuncs.com:9200/indexname/typename/_mapping'結果から取得されたフィールド：
{ "indexname": { "mappings": { "typename": { "properties": { "field1": { "type": "text" }, "field2": { "type": "long" }, "field3": { "type": "double" } } } } } }返された結果の properties 下のフィールドが、インデックスのすべてのフィールドおよび属性定義です。たとえば、上記のインデックスには field1、field2、field3 の 3 つのフィールドが含まれています。
Elasticsearch から他のデータソースにオフラインでデータを同期する際に、インデックス名が毎日変更される場合のインデックス名設定方法を教えてください。
インデックス構成に日付スケジューリング変数を追加できます。インデックス文字列は日付に基づいて計算され、Elasticsearch Reader のインデックス名が自動的に変更されます。この構成には、日付変数の定義、インデックス変数の構成、タスクの公開および実行の 3 つのステップが含まれます。
日付変数の定義：同期タスクのスケジューリング構成で、日付変数を定義するためのパラメーターを追加します。以下の例では、var1 はタスク実行時刻（当日）を示し、var2 はタスクのビジネステーブル日付（前日）を示します。
インデックス変数の構成：タスクをスクリプトモードに切り替え、Elasticsearch Reader インデックスを ${variable_name} の形式で構成します（下図参照）。
タスクの公開および実行：検証後、タスクをオペレーションセンターに送信して公開します。定期スケジューリングタスクとして実行するか、バックフィルデータ機能を使用して実行します。
パラメーター付きで実行 ボタンをクリックして、直接タスクを実行して検証します。パラメーター付きで実行すると、タスク構成で使用されるスケジューリングシステムパラメーターが置き換えられます。実行後、ログを確認して、同期されたインデックスが期待通りかどうかを検証します。
説明パラメーター付きでタスクを実行する際は、直接パラメーター値を入力して置き換えテストを行ってください。
前の検証が期待通りの場合、タスク構成は完了です。保存 をクリックしてから 送信 をクリックして、同期タスクを本番環境に送信します。
標準モードのワークスペースでは、デプロイ をクリックしてデプロイセンターに移動し、同期タスクを本番環境にデプロイする必要があります。
結果：以下に構成されたインデックスと実際のランタイムインデックスを示します。
スクリプトインデックスは次のように構成されています：
"index": "esstress_1_${var1}_${var2}"。ランタイムインデックスは次のように解決されます：
esstress_1_20230106_20230105。
オフライン同期タスクのテーブル名をカスタマイズするにはどうすればよいですか？
テーブル名が orders_20170310、orders_20170311、orders_20170312 のように一定のパターンに従っており、テーブルが日ごとに命名され、同じスキーマを共有している場合、「スケジューリングパラメーターの設定」で説明されているスケジューリングパラメーターを使用してテーブル名をカスタマイズできます。これにより、毎日深夜にソースデータベースから前日のテーブルデータを自動的に読み取ることができます。
たとえば、今日が 2017 年 3 月 15 日の場合、タスクは自動的にソースデータベースの orders_20170314 テーブルからデータを読み取ります。
スクリプトモードでは、ソーステーブル名を変数（例：orders_${tablename}）に変更します。テーブルが日ごとに命名され、毎日前日のデータを読み取る必要があるため、タスクパラメーター構成で変数値を tablename=${yyyymmdd} に設定します。
スケジューリングパラメーターの詳細については、「スケジューリングパラメーター」をご参照ください。
オフライン同期ノードを設定する際にすべてのテーブルを表示できない場合の対処方法を教えてください。
オフライン同期ノードを設定する際、ソースの選択 セクションには、選択したデータソースの最初の 25 テーブルのみがデフォルトで表示されます。テーブルが多すぎる場合は、テーブル名を入力して検索するか、スクリプトモードで開発を行ってください。
MaxCompute (ODPS) テーブルからデータを読み取る際に行を追加する際の注意点
定数を入力できます。値はシングルクォーテーションで囲む必要があります（例：'abc'、'123'）。
スケジューリングパラメーターを使用できます（例：'${bizdate}'）。スケジューリングパラメーターの詳細については、「スケジューリングパラメーター」をご参照ください。
同期したいパーティション列（例：pt）を入力できます。
入力した値が解析できない場合、タイプは 'Custom' と表示されます。
ODPS 関数はサポートされていません。
手動で追加された列が Custom と表示される場合（例：MaxCompute パーティション列、または LogHub データプレビューでプレビューされていない列）でも、実際のタスク実行には影響しません。
MaxCompute (ODPS) テーブルからデータを読み取る際にパーティションフィールドを同期するにはどうすればよいですか？
フィールドマッピングセクションで [行の追加] を選択し、パーティション列名（例：pt）を入力します。
MaxCompute (ODPS) テーブルからデータを読み取る際に複数のパーティションからデータを同期するにはどうすればよいですか？
読み取るデータのパーティション情報。
ODPS パーティション構成は Linux シェルのワイルドカードをサポートしています。* はゼロ個以上の文字を表し、? は任意の 1 文字を表します。
デフォルトでは、読み取るパーティションが存在している必要があります。パーティションが存在しない場合、タスクはエラーで失敗します。パーティションが存在しない場合でもタスクを成功させるには、スクリプトモードに切り替えて、ODPS パラメーター セクションに
"successOnNoPartition": true構成を追加します。
たとえば、test というパーティションテーブルに pt=1,ds=hangzhou、pt=1,ds=shanghai、pt=2,ds=hangzhou、pt=2,ds=beijing の 4 つのパーティションが含まれている場合、異なるパーティションからデータを読み取るための構成は次のとおりです：
pt=1,ds=hangzhou パーティションからデータを読み取るには、パーティション情報を次のように構成します：
"partition":"pt=1,ds=hangzhou"。pt=1 下のすべてのパーティションからデータを読み取るには、パーティション情報を次のように構成します：
"partition":"pt=1,ds=*"。test テーブル全体のすべてのパーティションからデータを読み取るには、パーティション情報を次のように構成します：
"partition":"pt=*,ds=*"。
さらに、ニーズに基づいてパーティションデータをフィルタリングする条件を設定できます（以下の操作にはスクリプトモードへの切り替えが必要です）：
最大パーティションを指定するには、
/*query*/ ds=(select MAX(ds) from DataXODPSReaderPPR)構成を追加します。条件でフィルタリングするには、
/*query*/ pt+expression構成に該当する条件を追加します。たとえば、/*query*/ pt>=20170101 and pt<20170110は、2017 年 1 月 1 日（含む）以降、2017 年 1 月 10 日（含まない）以前の pt パーティションのすべてのデータを取得します。
/*query*/ は、その後に続く内容が WHERE 条件として認識されることを示します。
列名に予約キーワードが含まれているために同期タスクが失敗する場合の対処方法を教えてください。
原因：列構成に予約キーワードまたは数字で始まるフィールドが含まれています。
解決策：Data Integration 同期タスクをスクリプトモードに切り替え、列構成内の特殊フィールドをエスケープします。スクリプトモードでのタスク構成の詳細については、「スクリプトモード構成」をご参照ください。
MySQL のエスケープ文字は
`keyword`です。Oracle および PostgreSQL のエスケープ文字は
"keyword"です。SQL Server のエスケープ文字は
[keyword]です。
以下の例は MySQL を使用しています：
MySQL データソースを例にとります：
aliyun という名前のテーブルを作成するには、次のステートメントを実行します：
create table aliyun (`table` int ,msg varchar(10));ビューを作成し、テーブル列にエイリアスを割り当てるには、次のステートメントを実行します：
create view v_aliyun as select `table` as col1,msg as col2 from aliyun;説明"table" は MySQL の予約キーワードです。データ同期中に生成されたコードでエラーが発生します。ビューを作成し、"table" 列にエイリアスを使用する必要があります。
テーブルの列名として予約キーワードを使用しないことを推奨します。
上記のステートメントを実行して予約キーワードを使用する列にエイリアスを割り当てた後、同期タスクを構成する際に aliyun テーブルではなく v_aliyun ビューを選択します。
Loghub のフィールドにデータが含まれているのに、同期後に空になる
このプラグインはフィールド名の大文字と小文字を区別します。Loghub リーダーの列構成を確認してください。
Loghub からの読み取り時にデータが欠落する
Data Integration は、データが Loghub に入った時刻を使用します。Loghub コンソールで、データの receive_time メタデータフィールドがタスクで設定された時間範囲内にあるかどうかを確認してください。
Loghub からの読み取り時にフィールドマッピングで予期しないフィールドが表示される
このような場合は、コンソールで列構成を手動で編集してください。
Kafka リーダーで endDateTime を設定して同期するデータの終了時刻を指定しても、送信先にこの時刻以降のデータが見つかる
Kafka Reader はバッチでデータを読み取ります。バッチに endDateTime を超えるレコードが含まれている場合、同期は停止しますが、そのバッチ内で endDateTime を超えるデータは送信先に書き込まれたままになります。
skipExceedRecord 設定項目を使用して、超過データを同期するかどうかを指定できます。詳細については、「Kafka Reader」をご参照ください。[超過データをスキップする設定は、データ損失を引き起こす可能性があるため推奨されません。]
Kafka の max.poll.records パラメーターを設定して、1 回のリクエストでプルされるデータ量を指定できます。同時実行数と組み合わせることで、超過する可能性のあるデータ量を制御できます。超過データ ＜ max.poll.records × 同時実行数
Kafka のデータ量が少ないにもかかわらず、Kafka タスクがデータを読み取らずに終了せずに実行され続けるのはなぜですか？
原因：
これは通常、指定された同期終了ポリシーが指定された終了オフセットに到達していないために発生します。この場合、読み取りオフセットが開始オフセットと終了オフセットの間にあるすべてのパーティションについて、各パーティションは指定された終了オフセット以上となるオフセットを持つ少なくとも 1 つのレコードを読み取るまで、タスクは終了しません。そうでない場合、タスクはデータをプルするために再試行を続けます。
解決策：
この場合、Kafka パーティション数を減らすか、各 Kafka パーティションに定期的にハートビートレコードを書き込むことを推奨します。これにより、同期タスクが終了条件を満たしやすくなります。
OSS への書き込みファイルからランダムな文字列を削除するにはどうすればよいですか？
OSS Writer は、OSS がディレクトリをシミュレートするためにファイル名を使用するファイル名でファイルを書き込みます。OSS にはオブジェクト名に関する次の制限があります。「object」: "datax" を使用する場合、書き込まれるオブジェクトは datax で始まり、ランダムな文字列のサフィックスが追加されます。ファイル数は、実際の分割タスク数に依存します。
ランダムな UUID サフィックスが不要な場合は、「writeSingleObject」: "true" を設定することを推奨します。詳細については、「OSS Writer」の writeSingleObject の説明をご参照ください。
詳細については、ドキュメントをご参照ください：[OSS Writer] (OSS Writer)
MySQL のシャードテーブルを単一の MaxCompute テーブルに同期するにはどうすればよいですか？
MySQL Reader プラグインドキュメントを参照してタスクを構成できます：「MySQL Reader」
WHERE 条件にインデックスがなく全表スキャンが発生するために同期が遅くなる
シナリオ例
実行された SQL は次のとおりです：
select bid,inviter,uid,createTime from `relatives` where createTime>='2016-10-2300:00:00'and reateTime<'2016-10-24 00:00:00';実行開始時刻は 2016-10-25 11:01:24.875、結果の返却開始時刻は 2016-10-25 11:11:05.489 でした。同期プログラムはデータベースが SQL クエリ結果を返すのを待機しており、そのために MaxCompute の実行が長時間待機していました。
原因
WHERE 条件の createTime 列にインデックスがなく、全表スキャンが発生しています。
解決策
where 条件にはインデックス付きの列を使用することを推奨します。必要に応じてインデックスを追加することもできます。
utf8mb4 文字セットの MySQL テーブルに同期する際に中国語文字が文字化けする場合の対処方法を教えてください。
JDBC URL を使用してデータソースを追加します。JDBC URL を次の形式に変更することを推奨します：jdbc:mysql://xxx.x.x.x:3306/database?com.mysql.jdbc.faultInjection.serverCharsetIndex=45。詳細については、「MySQL データソースの追加」をご参照ください。
API モードでデータを同期する際に、ソース側の関数（MaxCompute 関数など）を使用した集約はサポートされていますか？たとえば、ソーステーブルの列 a と b を Lindorm のプライマリキーとして使用する場合
API 同期モードはソース側の関数をサポートしていません。まずソース側の関数を使用してデータを処理し、その後データをインポートする必要があります。
同期されたテーブルの TTL は ALTER 文でのみ変更できますか？
TTL はテーブルレベルで設定されます。このオプションは同期タスクの設定では利用できません。
Elasticsearch Reader はオブジェクトまたはネストされたフィールドのプロパティをどのように同期しますか？（例：object.field1 の同期）
オブジェクトフィールドのプロパティを同期するには、スクリプトモードを使用する必要があります。スクリプトモードでは、multi パラメーターを次のように構成し、column を property.subproperty の形式で指定します。
"multi":{
"multi":true
}構成例を以下に示します：
#Example:
##Data in ES
"hits": [
{
"_index": "mutiltest_1",
"_type": "_doc",
"_id": "7XAOOoMB4GR_1Dmrrust",
"_score": 1.0,
"_source": {
"level1": {
"level2": [
{
"level3": "testlevel3_1"
},
{
"level3": "testlevel3_2"
}
]
}
}
}
]
##Reader configuration
"parameter": {
"column": [
"level1",
"level1.level2",
"level1.level2[0]"
],
"multi":{
"multi":true
}
}
##Writer result: 1 row with 3 columns, column order matches reader configuration
COLUMN VALUE
level1: {"level2":[{"level3":"testlevel3_1"},{"level3":"testlevel3_2"}]}
level1.level2: [{"level3":"testlevel3_1"},{"level3":"testlevel3_2"}]
level1.level2[0]: {"level3":"testlevel3_1"}ODPS の文字列フィールドを ES に同期した後に両側に余分な引用符が表示されるのはなぜですか？ソースの JSON 型文字列を ES の NESTED オブジェクトとして同期できますか？
文字の前後に表示される余分な二重引用符は、Kibana ツールの表示上の問題です。実際のデータには余分な二重引用符は含まれていません。実際のデータを確認するには、curl コマンドまたは Postman を使用してください。データを取得する curl コマンドは次のとおりです：
//es7 curl -u username:password --request GET 'http://esxxx.elasticsearch.aliyuncs.com:9200/indexname/_mapping' //es6 curl -u username:password --request GET 'http://esxxx.elasticsearch.aliyuncs.com:9200/indexname/typename/_mapping'
ES の書き込みフィールドタイプを nested に設定することで、ODPS の JSON 型文字列データを nested 形式で ES に同期できます。以下の例では、name フィールドを nested 形式で ES に同期します。
同期構成：name フィールドのタイプを nested に設定します。
同期結果：name フィールドは nested オブジェクトタイプになります。
ソースデータ string "[1,2,3,4,5]" を ES に配列形式で同期するにはどうすればよいですか？
配列タイプを ES に書き込むには 2 つの構成方法があります。ソースデータ形式に基づいて適切な同期方法を選択できます。
ソースデータを JSON 形式で解析して ES に配列タイプとして書き込みます。たとえば、ソースデータが "[1,2,3,4,5]" の場合、
json_array=trueを構成してソースデータを解析し、ES フィールドに配列として書き込みます。ColumnList をjson_array=trueに設定します。ウィザードモード構成：
スクリプトモード構成：
"column":[ { "name":"docs", "type":"keyword", "json_array":true } ]
ソースデータをデリミタで解析して ES に配列タイプとして書き込みます。たとえば、ソースデータが "1,2,3,4,5" の場合、デリミタ splitter="," を構成してデータを解析し、ES フィールドに配列として書き込みます。
制限事項：
1 つのタスクでは 1 つのデリミタのみをサポートします。splitter はグローバルに一意であり、複数の配列フィールドに対して異なるデリミタを構成することはできません。たとえば、ソース列が col1="1,2,3,4,5" および col2="6-7-8-9-10" の場合、各列に対して個別に splitter を構成することはできません。
splitter は正規表現として構成できます。たとえば、ソース列の値が "6-,-7-,-8+,*9-,-10" の場合、splitter:".,." を構成できます。これはウィザードモードでサポートされています。
ウィザードモード構成：
splitter：デフォルト値は "-,-" です。スクリプトモード構成：
"parameter" : { "column": [ { "name": "col1", "array": true, "type": "long" } ], "splitter":"," }
自己作成インデックスのネストされたプロパティタイプが keyword に設定されているにもかかわらず、自動生成（cleanup=true で同期タスクを実行）後にネストされたプロパティタイプが keyword に変更されるのはなぜですか？
#Original mappings
{
"name":"box_label_ret",
"properties":{
"box_id":{
"type":"keyword"
}
}
#After cleanup=true rebuild, it becomes
{
"box_label_ret": {
"properties": {
"box_id": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore_above": 256
}}}}
}原因：
ネストされたタイプの場合、Elasticsearch Writer はトップレベルのマッピングのみを使用し、ES にネストされた複雑なタイプを自動適応させます。プロパティタイプを text に変更し、fields: keyword を追加する動作は、ES の自動適応動作であり、ES の使用には影響しません。特定のマッピング形式が必要な場合は、「Elasticsearch Writer」をご参照ください。
解決策：
同期タスクを実行する前に、必要な ES インデックスマッピングを作成し、ES 同期タスクで cleanup を false に設定してから実行する必要があります。
ES へのデータ書き込み時に、認証されていないリクエストが最初に送信されますが、ユーザー名の検証が必要なためリクエストが失敗します。すべてのリクエストデータがログに記録され、毎日大量の監査ログが生成されます。これを処理するにはどうすればよいですか？
原因：
HttpClient は通信を確立する際に、まず認証されていないリクエストを送信するように設計されています。認証要件（応答に基づいて認証方式が決定される）を受信した後、認証済みのリクエストを送信します。ES へのデータ書き込みのたびに通信セッションが確立されるため、書き込み操作のたびに認証されていないリクエストが生成されます。これにより、データ書き込みのたびに監査ログに記録されます。
解決策：
スクリプトモードで
"preemptiveAuth":true構成を追加する必要があります。
Elasticsearch Writer で設定された Settings がインデックス作成時に反映されないのはなぜですか？
原因：
#Incorrect configuration "settings": { "index": { "number_of_shards": 1, "number_of_replicas": 0 } } #Correct configuration "settings": { "number_of_shards": 1, "number_of_replicas": 0 }解決策：
Settings 構成は、インデックスが作成される場合にのみ有効です。インデックスは次のシナリオで作成されます：インデックスが存在しない場合、または
cleanup=trueの場合。cleanup=trueの場合、Settings 構成には "index" ラッパーは不要です。
Elasticsearch に Date 型フィールドとしてデータを同期するにはどうすればよいですか？
次の 2 つの方法で日付の書き込みを構成できます。ニーズに応じて適切な方法を選択してください。
リーダーから読み取ったコンテンツに基づいて、Elasticsearch の Date フィールドに直接データを書き込みます：
origin:true を構成して、読み取ったコンテンツを Elasticsearch に直接書き込みます。
"format" を構成して、Elasticsearch によるマッピング作成時にフィールドの format 属性を指定します。
"parameter" : { "column": [ { "name": "col_date", "type": "date", "format": "yyyy-MM-dd HH:mm:ss", "origin": true } ] }
タイムゾーン変換：Data Integration にタイムゾーン変換を実行させる必要がある場合は、Timezone パラメーターを追加します。
"parameter" : { "column": [ { "name": "col_date", "type": "date", "format": "yyyy-MM-dd HH:mm:ss", "Timezone": "UTC" } ] }
Elasticsearch Writer が外部バージョンを指定したためにデータの書き込みに失敗しました。この問題を解決するにはどうすればよいですか？
type:version 構成が指定されていますが、Elasticsearch は現在外部バージョンの指定をサポートしていません。
"column":[ { "name":"id", "type":"version" }, ]解決策：
type":"version" 構成を削除してください。Elasticsearch Writer は外部バージョンの指定をサポートしていません。
非構造化データソースのデータプレビューをクリックした際にフィールドがマッピングできないのはなぜですか？この問題を解決するにはどうすればよいですか？
症状：
データプレビュー をクリックすると、フィールドのバイト長が制限を超えていることを示す次のようなメッセージが表示されます。
原因：OOM エラーを防ぐために、データソースサービスはデータプレビューリクエストを処理する際にフィールド長をチェックします。単一の列が 1,000 バイトを超える場合、上記のメッセージが表示されます。このメッセージはタスクの正常な実行には影響しません。エラーを無視して直接 DataX タスクを実行できます。
説明ファイルが存在し、接続が正常な場合でも、以下の状況でデータプレビューが失敗することがあります：
ファイル内の単一行のバイト数が 10 MB の制限を超える場合。この場合、上記のプロンプトと同様にデータが表示されません。
ファイル内の単一行の列数が 1000 列の制限を超える場合。この場合、最初の 1000 列のみが表示され、1001 列目にプロンプトが表示されます。
MongoDB Reader は大文字と小文字を区別しますか？
データ読み取り中に、構成する Column.name は大文字と小文字を区別します。構成が正しくない場合、読み取られたデータが null になります。例：
MongoDB ソースデータ：
{ "MY_NAME": "zhangsan" }同期タスクの列構成：
{ "column": [ { "name": "my_name" } ] }
同期タスクで構成された列名のケースがソースデータと異なるため、データ読み取りが異常になります。
MongoDB Reader のタイムアウト時間を設定するにはどうすればよいですか？
タイムアウト時間パラメーターは cursorTimeoutInMs で、デフォルトは 600000 ms（10 分）です。このパラメーターは、MongoDB Server がクエリを実行するための合計時間を指定します（データ転送時間は含まれません）。完全に読み取るデータ量が多い場合、次のエラーが発生する可能性があります：MongoDBReader$Task - operation exceeded time limitcom.mongodb.MongoExecutionTimeoutException: operation exceeded time limit。
MaxCompute で列のフィルタリング、並べ替え、NULL パディングを実装するにはどうすればよいですか？
MaxCompute Writer を構成することで、MaxCompute がネイティブでサポートしていない列のフィルタリング、並べ替え、NULL パディングを実装できます。たとえば、インポートするフィールドのリストを指定するには、"column": ["*"] を構成してすべてのフィールドをインポートします。
MaxCompute テーブルに a、b、c の 3 つのフィールドがあり、c と b のフィールドのみを同期したい場合は、column を "column": ["c","b"] と構成します。これにより、リーダーの 1 番目および 2 番目の列がそれぞれ MaxCompute テーブルの c および b フィールドにインポートされ、新しく挿入された行の a フィールドは null に設定されます。
MaxCompute 列の構成エラーの対処
データ信頼性を確保し、余分な列データの損失によるデータ品質の問題を回避するために、MaxCompute Writer はテーブルの列数よりも多くの列を書き込もうとするとエラーを報告します。たとえば、MaxCompute テーブルに a、b、c のフィールドがある場合、3 列を超える列を書き込もうとすると MaxCompute Writer はエラーを報告します。
MaxCompute のパーティション設定に関する注意点
MaxCompute Writer は、最後のレベルのパーティションへのデータ書き込みのみをサポートします。フィールドに基づくパーティションルーティングなどの機能はサポートしていません。テーブルに 3 つのレベルのパーティションがある場合、パーティション構成で正確な 3 レベル目のパーティションを指定する必要があります。たとえば、3 レベル目のパーティションにデータを書き込むには、pt=20150101, type=1, biz=2 と構成できますが、pt=20150101, type=1 や pt=20150101 とは構成できません。
MaxCompute タスクの再実行とフェールオーバー
MaxCompute Writer は、"truncate": true を構成することで書き込みのべき等性を保証します。書き込みに失敗してタスクを再実行する場合、MaxCompute Writer は以前に書き込まれたデータをクリアして新しいデータをインポートし、再実行後のデータ整合性を保証します。実行中に他の例外によってタスクが中断された場合、データの原子性は保証されません。データはロールバックされず、自動的に再実行もされません。べき等性機能を利用してタスクを再実行し、データ整合性を確保する必要があります。
truncate が true に設定されている場合、指定されたパーティションまたはテーブル内のすべてのデータがクリアされます。このオプションは慎重に使用してください。
ソーステーブルにデフォルト値がある場合、Data Integration で作成された送信先テーブルにデフォルト値や非 NULL 制約などのプロパティは保持されますか？
送信先テーブルを作成する際、DataWorks はソーステーブルの列名、データ型、コメントのみを保持します。ソーステーブルのデフォルト値や制約（非 NULL 制約、インデックスなど）は保持しません。
自動採番主キー列を含む送信先テーブルに OTS Writer でデータを書き込むにはどうすればよいですか？
OTS Writer 構成には次の 2 項目を含める必要があります：
"newVersion": "true", "enableAutoIncrement": "true",自動採番主キー列名を OTS Writer で構成しないでください。
OTS Writer で構成された primaryKey エントリ数 + column エントリ数は、上流の OTS Reader データの列数と等しくなければなりません。
時系列モデル構成における _tag および is_timeseries_tag フィールドの理解方法を教えてください。
例：データレコードに [phone=xiaomi, RAM=8G, camera=LEICA] の 3 つのタグがあります。
データエクスポート例 (OTS Reader)
上記のタグを 1 つの列にマージしてエクスポートする場合は、次のように構成します：
"column": [ { "name": "_tags", } ],DataWorks はタグを次のような形式で 1 列のデータとしてエクスポートします：
["phone=xiaomi","camera=LEICA","RAM=8G"]phoneタグおよびcameraタグをエクスポートし、各タグを別の列としてエクスポートする場合は、次のように構成します："column": [ { "name": "phone", "is_timeseries_tag":"true", }, { "name": "camera", "is_timeseries_tag":"true", } ],DataWorks は次のような形式で 2 列のデータをエクスポートします：
xiaomi, LEICA
データインポート例 (OTS Writer)
上流のデータソース (Reader) に現在 2 列のデータがあります：
1 列目には：
["phone=xiaomi","camera=LEICA","RAM=8G"]が含まれています。もう 1 列には：6499 が含まれています。
両方の列をタグに追加したい場合、書き込み後のタグフィールドの期待される形式は次のとおりです：
次のように構成します："column": [ { "name": "_tags", }, { "name": "price", "is_timeseries_tag":"true", }, ],1 列目の構成は、
["phone=xiaomi","camera=LEICA","RAM=8G"]をタグフィールドに全体としてインポートします。2 列目の構成は、
price=6499をタグフィールドに個別のエントリとしてインポートします。
日時データをテキストに書き込む際にミリ秒を保持したり、カスタム日時形式を指定したりするにはどうすればよいですか？
同期タスクをスクリプトモードに切り替えた後、タスク設定ページの "setting" セクションに次の構成項目を追加します：
"common": {
"column": {
"dateFormat": "yyyyMMdd",
"datetimeFormatInNanos": "yyyyMMdd HH:mm:ss.SSS"
}
}
ここで：
dateFormat は、ソースの DATE 型（時・分・秒なし）をテキストに変換する際に使用する日付形式を指定します。
datetimeFormatInNanos は、ソースの DATETIME/TIMESTAMP 型（時・分・秒あり）をテキストに変換する際に使用する日付形式を指定します。ミリ秒までの精度を指定できます。
エラーメッセージと対処法
データ同期エラー：[TASK_MAX_SLOT_EXCEED]:Unable to find a gateway that meets resource requirements. 20 slots are requested, but the maximum is 16 slots.
考えられる原因：
同時実行数が高すぎ、リソースが不足しています。
解決策：
オフライン同期タスクの同時実行数設定を減らしてください。
コードレス UI を使用してオフライン同期タスクを構成する場合、チャネル制御設定の Expected Maximum Concurrency を減らしてください。詳細については、「コードレス UI でのチャネル制御の設定」をご参照ください。
コードエディタを使用してオフライン同期タスクを構成する場合、チャネル制御設定の Concurrent パラメーターを減らしてください。詳細については、「コードエディタでのチャネル制御の設定」をご参照ください。
データ同期エラー：OutOfMemoryError: Java heap space
このエラーが発生した後、次の操作を行う必要があります：
プラグイン構成が batchsize または maxfilesize パラメーターをサポートしている場合は、対応する値を減らしてください。
各プラグインが上記のパラメーターをサポートしているかどうかを確認できます。「サポートされているデータソースと同期ソリューション」ドキュメントに移動し、対応するプラグインをクリックしてパラメーターの詳細を確認してください。
同時実行数を減らしてください。
コードレス UI を使用してオフライン同期タスクを構成する場合、チャネル制御設定の Expected Maximum Concurrency を減らしてください。詳細については、「コードレス UI でのチャネル制御の設定」をご参照ください。
コードエディタを使用してオフライン同期タスクを構成する場合、チャネル制御設定の Concurrent パラメーターを減らしてください。詳細については、「コードエディタでのチャネル制御の設定」をご参照ください。
OSS ファイルなど、ファイルを同期している場合は、読み取るファイル数を減らしてください。
OSS データの読み取り時のエラー：AccessDenied The bucket you access does not belong to you.
データソース用に構成された AccessKey (AK) ユーザーがバケットに対する権限を持っていません。OSS データソース用に構成された AK ユーザーに、対応するバケットの権限を付与してください。
Redis へのハッシュストレージモードでの書き込み時のエラー：Code:[RedisWriter-04], Description:[Dirty data]. - source column number is in valid!
原因：
Redis がハッシュストレージモードを使用する場合、ハッシュ属性と値はペアで出現する必要があります。たとえば、ソースが
odpsReader: "column":[ "id", "name", "age", "address", ]と構成され、送信先が RedisWriter: "keyIndexes":[ 0 ,1] と構成されている場合、Redis では id と name がキーとして機能し、age が属性、address が値としてハッシュ型の Redis エントリに格納されます。ソースに 2 列しか構成されていない場合、ハッシュモードを使用して Redis にデータを格納することはできず、このエラーがスローされます。解決策：
2 列のみ必要な場合は、Redis String モードを構成してデータを格納してください。ハッシュモードを使用する必要がある場合は、ソース側で少なくとも 3 列を構成してください。
PostgreSQL データの読み取り時のエラー：org.postgresql.util.PSQLException: FATAL: terminating connection due to conflict with recovery
シナリオ：オフライン同期タスクを使用して PostgreSQL データを同期する際に、次のエラーが発生します：
org.postgresql.util.PSQLException: FATAL: terminating connection due to conflict with recovery考えられる原因：データベースからのデータのプルに時間がかかりすぎています。max_standby_archive_delay パラメーターおよび max_standby_streaming_delay パラメーターの値を増やしてください。詳細については、「スタンバイサーバーイベント」をご参照ください。
MySQL への書き込みまたは読み取り時のエラー：Application was streaming results when the connection failed. Consider raising value of 'net_write_timeout/net_read_timeout、' on the server.
原因：
net_read_timeout：DataX は splitPk に基づいて MySQL データを複数の同等サイズの SELECT ステートメントに分割します。これらの SQL ステートメントのいずれかが RDS 側で許可された最大実行時間を超えると、このエラーが発生します。
net_write_timeout：クライアントにブロックを送信するのを待つタイムアウトが小さすぎます。
解決策：
データソース URL 接続文字列にパラメーターを追加し、net_write_timeout/net_read_timeout をより大きな値に設定するか、RDS コンソールでパラメーターを調整してください。
推奨事項：
タスクを再実行できる場合は、タスクに自動再実行を構成することを推奨します。
例：jdbc:mysql://192.168.1.1:3306/lizi?useUnicode=true&characterEncoding=UTF8&net_write_timeout=72000
MySQL へのオフライン同期時のエラー：[DBUtilErrorCode-05]ErrorMessage: Code:[DBUtilErrorCode-05]Description:[Failed to write data to the configured destination table.]. - com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException: No operations allowed after connection closed
原因：
MySQL の wait_timeout パラメーターはデフォルトで 8 時間に設定されています。このタイムアウトに達した時点でデータ取得がまだ進行中の場合、同期タスクは中断されます。
解決策：
MySQL 設定ファイル my.cnf（Windows では my.ini）を編集します。MySQL セクションの下に次のパラメーター（秒単位）を追加します：wait_timeout=2592000 interactive_timeout=2592000。その後、MySQL を再起動し、次のステートメントを実行して設定が有効になっているかどうかを確認します：show variables like '%wait_time%'。
MySQL データベースの読み取り時のエラー：The last packet successfully received from the server was 902,138 milliseconds ago
CPU 使用率は正常ですがメモリ使用量が高い場合、接続が終了される可能性があります。
タスクを自動的に再実行できることを確認している場合は、失敗時に自動再実行を構成することを推奨します。詳細については、「自動再実行の設定」をご参照ください。
オフライン同期エラー：Communications link failure
読み取りエラー
症状：
データの読み取り時に次のエラーが発生します：
Communications link failure The last packet successfully received from the server was 7,200,100 milliseconds ago. The last packet sent successfully to the server was 7,200,100 milliseconds ago. - com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure考えられる原因：
データベースが SQL クエリを遅く実行しており、MySQL 読み取りタイムアウトが発生しています。
解決策：
where フィルター条件が構成されているかどうかを確認し、フィルター対象のフィールドにインデックスがあることを確認してください。
ソーステーブルにデータが多すぎる場合は、タスクを複数のタスクに分割することを推奨します。
クエリログを確認して、ブロックされた SQL ステートメントを見つけ、データベース管理者に解決を依頼してください。
書き込みエラー
症状：
データの書き込み時に次のエラーが発生します：
Caused by: java.util.concurrent.ExecutionException: ERR-CODE: [TDDL-4614][ERR_EXECUTE_ON_MYSQL] Error occurs when execute on GROUP 'xxx' ATOM 'dockerxxxxx_xxxx_trace_shard_xxxx': Communications link failure The last packet successfully received from the server was 12,672 milliseconds ago. The last packet sent successfully to the server was 12,013 milliseconds ago. More...考えられる原因：
スロークエリにより SocketTimeout が発生しています。TDDL データベース接続のデフォルトの SocketTimeout は 12 秒です。MySQL 側で SQL ステートメントの実行に 12 秒以上かかり、結果が返らない場合、エラー 4614 が報告されます。このエラーは、データ量が多い場合やサーバーがビジー状態の場合に時々発生する可能性があります。
解決策：
データベースが安定するまで待ち、同期タスクを再実行してください。
データベース管理者に連絡して、タイムアウト値を調整してもらってください。
バッチ同期エラー：Duplicate entry 'xxx' for key 'uk_uk_op'
症状：
Error updating database. Cause: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry 'cfc68cd0048101467588e97e83ffd7a8-0' for key 'uk_uk_op'。考えられる原因：Data Integration 同期タスクでは、同じノードの異なるインスタンスが同時に実行されることを許可していません。つまり、同じ JSON 構成を持つ同期タスクを同時に実行することはできません。たとえば、5 分間隔の同期タスクで、上流の遅延により 00:00 にスケジュールされていたインスタンスと 00:05 のインスタンスが両方とも 00:05 にトリガーされた場合、一方のインスタンスが開始に失敗する可能性があります。この問題は、タスクインスタンスがまだ実行中のときにバックフィルまたは再実行操作を実行した場合にも発生する可能性があります。
解決策：インスタンスの実行時間をずらしてください。毎時タスクの場合は、自己依存を構成してください。
バッチ同期エラー：plugin xx does not specify column
このエラーは、同期タスクのフィールドマッピングが誤って構成されているか、プラグインの column パラメーターが正しく構成されていないために発生する可能性があります。
フィールドマッピングが構成されているかどうかを確認してください。
プラグインの column パラメーターが正しく構成されているかどうかを確認してください。
MaxCompute (ODPS) テーブルデータの読み取り時のエラー：The download session is expired.
症状：
Code:DATAX_R_ODPS_005:Failed to read ODPS data, Solution:[Please contact the ODPS administrator]. RequestId=202012091137444331f60b08cda1d9, ErrorCode=StatusConflict, ErrorMessage=The download session is expired.考えられる原因：
バッチ同期タスクが MaxCompute からデータを読み取る際、MaxCompute Tunnel コマンドを使用してデータのアップロードおよびダウンロードを行います。Tunnel セッションのサーバー側の有効期間は 24 時間です。したがって、バッチ同期タスクが 24 時間以上実行された場合、タスクは失敗して終了します。Tunnel の詳細については、「Tunnel の概要」をご参照ください。
解決策：
バッチ同期タスクの同時実行数を増やし、データ量を適切に計画して、タスクが 24 時間以内に完了するようにしてください。
MaxCompute (ODPS) への書き込み時のブロック失敗エラー：Error writing request body to server
症状：
Code:[OdpsWriter-09], Description:[Failed to write data to the ODPS destination table.]. - Failed to write block:0 to the ODPS destination table, uploadId=[202012081517026537dc0b0160354b]. Please contact the ODPS administrator for assistance. - java.io.IOException: Error writing request body to server。考えられる原因：
考えられる原因 1：データ型の例外。ソースデータが ODPS データ型仕様に準拠していません。たとえば、値 4.2223 を ODPS decimal(18,10) データ型の列に書き込みます。
考えられる原因 2：ODPS ブロックまたは通信の例外。
解決策：
データ型を変換し、データ型仕様に準拠したデータを使用してください。
RestAPI Writer エラー：The JSON string found through path:[] is not an array type
RestAPI Writer には 2 つの書き込みモードがあります。複数のレコードを同期する場合、dataMode を multiData に設定する必要があります。詳細については、「RestAPI Writer の設定」をご参照ください。また、RestAPI Writer スクリプトに dataPath:"data.list" パラメーターを追加する必要があります。
Column を構成する際は、"data.list" プレフィックスを追加しないでください。
バッチ同期タスクのソースが Amazon RDS インスタンスの場合のエラー：Host is blocked
Amazon RDS インスタンスへの接続時に Host is blocked が返される場合、Amazon ロードバランサーのヘルスチェックを無効にする必要があります。無効にした後、ブロックエラーは発生しなくなります。
MongoDB の読み取り時のエラー：no master
現在、DataWorks 同期タスクはセカンダリ（レプリカ）ノードからのデータ読み取りをサポートしていません。セカンダリノードをデータソースとして構成した場合、次のエラーが報告されます：no master。
MongoDB の読み取り時のエラー：MongoExecutionTimeoutException: operation exceeded time limit
原因：
カーソルタイムアウト。
解決策：
cursorTimeoutInMs パラメーターの値を増やしてください。
MongoDB からのバッチ同期読み取りエラー：DataXException: operation exceeded time limit
タスクの同時実行数および読み取り用の BatchSize を増やしてください。
Elasticsearch からのバッチ同期読み取りエラー：ERROR ESReaderUtil - ES_MISSING_DATE_FORMAT, Unknown date value. please add "dataFormat". sample value:
原因：
Elasticsearch Reader が日付型フィールドの日付形式を解析できません。これは、対応する Elasticsearch データソースの日付フィールドのマッピングに format が設定されていないためです。
解決策：
dateFormat パラメーターを構成します。形式は ES 日付フィールドの形式と同じである必要があります。区切り文字として "||" を使用し、使用されているすべての日付型の形式を含める必要があります。例：
"parameter" : { "column": [ { "name": "col1", "type": "date" } ], "dateFormat" : "yyyy-MM-dd||yyyy-MM-dd HH:mm:ss", }ES データベース内のすべての日付フィールドのマッピングを format 値に設定します。
Elasticsearch からのバッチ同期読み取りエラー：com.alibaba.datax.common.exception.DataXException: Code:[Common-00], Describe:[The configuration file you provided contains errors. Please check your job configuration.] - Configuration error. The configuration information you provided is not valid JSON format: illegal ref, [ . Please provide configuration information in standard JSON format.
原因：
fastjson キーワード制限により、インデックスまたは列に $ref などのキーワードが存在する可能性があります。
解決策：
Elasticsearch Reader は、フィールド名に $ref キーワードを含むインデックスの同期をサポートしていません。詳細については、「Elasticsearch Reader」をご参照ください。
Elasticsearch へのバッチ同期書き込みエラー：version_conflict_engine_exception.
原因：
ES の楽観的ロックメカニズムがトリガーされています。現在のバージョン番号は xxx である必要がありますが、更新コマンドで渡されたバージョン番号が異なるため、バージョン競合が発生しています。更新中に誰かが同時にインデックスデータを削除しています。
解決策：
データ削除アクティビティがないかどうかを確認してください。
同期タスクの書き込みモードを Update から Index に変更してください。
Elasticsearch へのバッチ同期書き込みエラー：illegal_argument_exception.
原因：
Column フィールドの similarity や properties などの高度な属性を構成する際、プラグインがそれらを認識するには other_params パラメーターが必要です。
解決策：
Column に
other_paramsを構成し、other_paramsに similarity を追加します（以下参照）：{"name":"dim2_name",...,"other_params":{"similarity":"len_similarity"}}
ODPS Array フィールドタイプデータを Elasticsearch にバッチモードで同期する際のエラー：dense_vector
原因：
現在、Elasticsearch へのバッチ同期書き込みは dense_vector 型をサポートしていません。サポートされている型は次のとおりです：
ID,PARENT,ROUTING,VERSION,STRING,TEXT,KEYWORD,LONG, INTEGER,SHORT,BYTE,DOUBLE,FLOAT,DATE,BOOLEAN,BINARY, INTEGER_RANGE,FLOAT_RANGE,LONG_RANGE,DOUBLE_RANGE,DATE_RANGE, GEO_POINT,GEO_SHAPE,IP,IP_RANGE,COMPLETION,TOKEN_COUNT,OBJECT,NESTED;解決策：
Elasticsearch Writer でサポートされていない型については、次のアプローチを使用します：
Elasticsearch Writer を使用してインデックスマッピングを作成しないでください。代わりにカスタムマッピングを使用してください。
対応する型を NESTED に変更してください。
構成を次のように変更してください：
dynamic = true、cleanup=false。
オンプレミスの Hive へのオフライン同期時にエラーが発生：Could not get block locations.
考えられる原因：
mapred.task.timeout パラメーターが小さすぎる値に設定されている可能性があります。Hadoop がタスクを終了させ、一時ディレクトリをクリーンアップするため、一時データが後続の操作で利用できなくなります。
解決策：
mapred.task.timeout パラメーターの値を増やしてください。
MongoDB 同期タスクでエラーが発生：no such cmd splitVector
考えられる原因：
同期タスクの実行時に、
splitVectorコマンドがデフォルトでタスクの分割に使用されます。一部の MongoDB バージョンはsplitVectorコマンドをサポートしていないため、no such cmd splitVectorエラーが発生します。解決策：
同期タスク設定ページに移動し、上部の [スクリプトに変換]
ボタンをクリックして、タスクをスクリプトモードに変換します。MongoDB パラメーター構成で、次のパラメーターを追加します。
"useSplitVector" : falseこれにより、
splitVectorコマンドの使用を回避できます。
MongoDB オフライン同期でエラーが報告される: 更新適用後、(不変の) フィールド '_id' が _id: "2" に変更されていたことが判明しました
エラー症状：
同期タスクで、ウィザードモードを例にとると、書き込みモード（上書き） を はい に設定し、
_id以外のフィールドを ビジネスプライマリキー として構成した場合、この問題が発生する可能性があります。
考えられる原因：
書き込まれるデータには、_Id が構成された ビジネスプライマリキー（たとえば、上記の構成例の
my_id）と一致しないレコードが含まれています。解決策：
オプション 1：オフライン同期タスクを変更して、構成された ビジネスプライマリキー が _Id と一致するようにします。
オプション 2：データを同期する際に _Id をビジネスプライマリキーとして使用します。
オフラインタスクでエラーが発生：MongoDBReader$Task - operation exceeded time limitcom.mongodb.MongoExecutionTimeoutException: operation exceeded time limit.
エラーメッセージ：データ同期タスクの実行中に、
MongoDBReader$Task - operation exceeded time limitcom.mongodb.MongoExecutionTimeoutException: operation exceeded time limitエラーでタスクが失敗します。考えられる原因：完全データのプルが大きすぎます。
解決策：
同時実行数を増やしてください。
BatchSize を減らしてください。
リーダー側のパラメーター構成で、
cursorTimeoutInMsパラメーターを追加し、3600000 ms などの大きな値に設定してください。