使用説明

ダウンロード

フォーカスモード

フォントサイズ

最終更新日: 2026-10-16 18:15:30

AI翻訳

カテゴリ
説明
同期オブジェクト
1. 基本テーブル、ビューの同期のみをサポートし、関数、トリガー、ストアドプロシージャなどのオブジェクトの同期はサポートしません。
2. 相互に関連するデータオブジェクトは同時に同期する必要があります。そうしないと、同期が失敗する可能性があります。
3. 増分同期段階では、ソースデータベースのテーブル名に「TDSQLagent」、「tdsql_sub」という文字が含まれている場合、フィルタリングされたり、同期異常を引き起こしたりする可能性があります。これらのテーブル名はTDSQLシステムの一時テーブル名と同じであるためです。TDSQLagentは拡張時の一時テーブルであり、tdsql_subテーブルはhash-lishおよびhash-rangeのサブテーブルです。したがって、ソース側で同期対象のテーブル名をこれらのタイプに設定しないことをお勧めします。
ソースデータベースへの影響
1. データ同期時、DTSは同期タスクを実行するアカウントを使用してソースデータベースにシステムデータベース`__tencentdb__`を書き込み、トランザクションマークIDなどのメタ情報を記録します。ソースデータベースにおける`__tencentdb__`への読み書き権限を確保する必要があります。
後続のデータ比較問題を特定できるようにするため、同期タスク終了後もソースデータベース内の`__tencentdb__`は削除されません。
`__tencentdb__`システムデータベースが占有する容量は非常に小さく、ソースデータベースのストレージ容量の約1000分の1から1万分の1です（例えば、ソースデータベースが50GBの場合、`__tencentdb__`システムデータベースは約5MB～50MBです）。また、シングルスレッドと接続待機メカニズムを採用しているため、ソースデータベースのパフォーマンスにはほとんど影響を与えず、リソースを奪い合うこともありません。
2. デフォルトではロックフリー同期方式を採用し、フルデータエクスポート段階ではソースデータベースにグローバルロック（FTWRL）をかけず、主キーがないテーブルにのみテーブルロックをかけます。
ターゲット側 Kafka の要件
1. ターゲット側Kafkaのバージョンは、現在Tencent Cloudで購入可能なプロフェッショナル版とスタンダード版のみサポートされており、バージョン1.1.1以降が対象です。すでに販売終了となった物理マシンのスタンダード版はターゲット側としてサポートされていません。
2. ターゲットKafkaでメッセージ保持期間とメッセージサイズの上限を変更する必要があります。
メッセージ保存期間は3日に設定することをお勧めします。保存期間を過ぎたデータは削除されます。ユーザーは設定した期間内に速やかに消費してください。メッセージサイズの上限、つまりKafkaが受信できる単一メッセージのメモリサイズは、ソースデータベースのテーブル内の単一行データの最大値より大きく設定する必要があります。これにより、ソースデータベースのデータがすべて正常にKafkaに配信されます。
3. ターゲットTopicは空にすることをお勧めします。また、同期タスク中は、ターゲット側で同期対象として選択したTopicにデータを書き込まないでください。そうしないと、メッセージの不整合やタスクエラーが発生する可能性があります。
データ同期の説明
1. InnoDB、MyISAM、TokuDBの3種類のデータベースエンジンのみ同期をサポートします。これら以外のデータエンジンテーブルが存在する場合、デフォルトでスキップされ同期されません。
2. 同じタスクは複数のTopicに関連付けることができますが、同じTopicを同時に複数の同期タスクで使用することはできません。そうしないと、データの不整合が発生し、消費されるデータが複数の異なるタスクのデータとなり、タスクの再試行などのシナリオでデータ処理の異常やタスクエラーが発生する可能性があります。
3. 全量同期段階では、10万件のデータを同期するごとに、ターゲット側Kafkaにcheckpointメッセージが1件挿入され、現在のデータ同期位置を示します。
4. DTSがターゲット側Kafkaに同期する単一メッセージには性能上限があります。ユーザーはソースデータベース内の単一行データを8MB以下に抑えることをお勧めします。そうしないと、同期中にエラーが発生する可能性があります。
5. ユーザーが同期中に特定のテーブルに対してrename操作を行うことが確実な場合、データはターゲットkafkaに配信され、パーティションルールは新しいテーブル名に基づいてtopicとpartitionをマッチングします。
6. 増分同期中に、ソースデータベースでSTATEMENT形式のBinlogステートメントが生成された場合、同期が失敗します。
7. ALTER VIEWステートメントはサポートされていません。このステートメントが検出された場合、タスクはスキップされ、同期されません。 
8. ソース側インスタンス全体を選択しての同期はサポートされていません。後続の同期タスクで、ソース側に新しいデータベースを作成する操作（CREATE DATABASE）がある場合、同期タスクの開始前に、ターゲット側で該当するデータベースオブジェクトをあらかじめ作成することをお勧めします。
9. 同期タスクの進行中に、ソース側でCREATE TABLE、RENAME TABLEの操作が発生した場合、設定段階で同期オブジェクトを選択する際に、該当テーブルが属するデータベース全体を選択してください。そうしないと、新規作成されたテーブルやRENAME後のテーブルはターゲット側に同期されません。
10. 同期タスクがすでに開始されている場合、ユーザーがターゲット側Ckafkaのパーティション数を変更した後、タスクの再起動をトリガーする必要があります（先に一時停止してから再開することで再起動を実現します）。これにより、データは新しく追加されたパーティションに配信されます。
データ消費の説明
同期タスクの前に、ソースデータベースに既に存在する全量データは、データ書き込みの正確な時間がないため、コンシューマー側のデモではhappenAtフィールドが1970-01-01 08:00:00と表示されますが、この時間フィールドは気にする必要はありません。増分データを消費する際には、時間フィールドは正しく表示されます。
再起動の影響
同期タスク中に、タスクの再起動が発生した場合（ソースデータベースでHA切り替えが発生すると再起動し、バックグラウンドチェックでタスク異常が検出されると再起動します）、可能性があり、ターゲット側Kafkaに同期されるデータに重複が発生する可能性があります。
DTSは最小データユニット単位で同期を行います（全量段階では単一テーブルオブジェクトの1ブロックのデータが最小データユニットとなり、増分段階では1つのポジションがマークされるごとに1つのデータユニットとなります）。再起動時に、ちょうど1つのデータユニットの同期が完了している場合は、データの重複は発生しません。再起動時に、1つのデータユニットがまだ同期中である場合は、再度起動した後にこのデータユニットを再同期してデータの整合性を保つ必要があるため、データの重複が発生します。
ユーザーが重複データを気にする場合は、データを消費する際に重複排除ロジックを設定してください。
操作制限
同期中に以下の操作を行わないでください。行うと同期タスクが失敗します。
1. フルエクスポート段階では、ソースデータベース上でデータベースまたはテーブル構造を変更するDDL操作を実行しないでください。
2. ソースデータベースおよびターゲット側のユーザー情報（ユーザー名、パスワード、権限を含む）とポート番号を変更、削除しないでください。
3. ソースデータベース上でBinlogを削除する操作を実行しないでください。
データ型
1. TDSQL MySQLをソースデータベースとして使用し、proxy方式で接続するシナリオでは、ソースデータベースでfloatデータ型を使用すると、フル段階のデータ精度が不正確になります。データ精度を保持する必要がある場合は、doubleデータ型の使用をお勧めします。フル段階の精度問題による具体的な影響は以下の通りです：
フル段階と増分段階のデータ同期の精度が一致しません。
floatをキー値として使用する場合、フル段階と増分段階で操作されるPKデータが一致しません。
2. DTSは全量データ同期段階で、ソースデータベースのデータをエクスポートし、ターゲット側Kafkaにインポートします。いずれもutf8mb4文字セットを使用し、文字セットが認識されないことによる文字化けを防ぎます。
3. Geometry関連のデータ型はサポートされていません。このタイプのデータが検出された場合、タスクはエラーを報告します。
トランザクション
1つのトランザクションにDML文とDDL文が同時に含まれるシナリオはサポートされていません。この状況が発生すると、タスクはエラーを報告します。
HA切り替えと拡張
1. ソースデータベースが非GTIDデータベースの場合、DTSはソース側のHA切り替えをサポートしません。ソース側のTDSQL MySQLで切り替えが発生すると、DTSの増分同期が中断される可能性があります。
2. DTSがSETでTDSQL MySQLに直接接続するシナリオでは、TDSQL MySQLの拡張はサポートされません。ProxyでTDSQL MySQLに接続するシナリオでは、TDSQL MySQLの論理拡張がサポートされます。水平拡張時にDTSがエラーを報告する可能性があります。
パーティションテーブル同期
1. プライマリ/セカンダリパーティションテーブルの構文は仕様に準拠する必要があります。プライマリHashパーティションテーブルは、shardkey方式でのみ作成できます。
TDSQL MySQLでパーティションテーブルを作成するための主要な構文は以下のとおりです。詳細な構文については、TDSQL MySQL公式ドキュメントを参照してください。
1.1 プライマリパーティション
プライマリHashパーティション：shardkey
プライマリRangeパーティション：TDSQL_DISTRIBUTED BY RANGE
プライマリListパーティション：TDSQL_DISTRIBUTED BY LIST
1.2 セカンダリパーティション
プライマリHashパーティション+セカンダリRange/Listパーティション：shardkey + PARTITION BY RANGE/LIST
プライマリRangeパーティション+セカンダリRange/Listパーティション：TDSQL_DISTRIBUTED BY RANGE + PARTITION BY RANGE/LIST
プライマリListパーティション+セカンダリRange/Listパーティション：TDSQL_DISTRIBUTED BY LIST + PARTITION BY RANGE/LIST
1.3 新規セカンダリパーティション
プライマリHashパーティション+セカンダリRange/Listパーティション：TDSQL_DISTRIBUTED BY HASH + TDSQL_PARTITION BY RANGE/LIST
2. 増分同期段階では、並行DDL操作はサポートされていません。前のDDLが有効になってから次のDDLを実行する必要があります。そうしないと、DDLの順序乱れによってエラーが発生する可能性があります。また、同じ名前のテーブルに対してcreate、drop、create操作を迅速に実行することもサポートされていません。そうしないと、テーブルタイプエラーが発生する可能性があります。
開始位置の指定
初期化タイプをいずれもチェックしない場合、増分同期のみを実行することを示し、増分同期の開始位置を設定できます。現在、この機能を使用するにはチケットを提出して申請する必要があります。
1. 増分同期タスクは、設定された時点からデータの同期を開始します。設定可能な時点の範囲は、過去14日間から現在時刻までです。
2. 全量同期と増分同期を2つのタスクに分けて実行する場合、増分同期を実行する際には、DTSがすでに同期した全量データの時点1と設定した時点2の間に、DDL（CREATE TABLE、ALTER TABLE、DROP TABLE、RENAME TABLE、CREATE INDEX、DROP INDEX）によるデータ変更が存在してはなりません。存在する場合、タスクはエラーを報告します。
3. 設定された指定時点1から増分タスクの開始時点2までの間（タスクステップが「指定ポイントの検索」から「増分同期」に移行した時点で開始とみなされます）、ソースデータベース操作の注意事項は以下の通りです。
ソースデータベースでは、マスタースレーブ切り替え、シャードの追加、スタンバイ機の再作成を行わないことをお勧めします。そうしないと、DTSがソースデータベースのGTIDポジションを取得する際に影響が出る可能性があります。
ソース側は同期オブジェクトに関係のないDDLを操作できますが、前のDDLがターゲット側に同期された後に新しいDDLを実行することを保証する必要があります。DDLを集中的に実行すると、タスクエラーが発生する可能性があります。
ソース側では同期オブジェクトに関係するDDL（CREATE TABLE、ALTER TABLE、DROP TABLE、RENAME TABLE、CREATE INDEX、DROP INDEX）を操作することはできません。そうしないと、同期タスクがエラーを報告します。
4. 指定時点同期はBinlog内のcontextの時間（SET TIMESTAMP=XXXX）に基づいてそのGTIDを判断するため、同期データの正確性を保証するために、ユーザーがこのcontextを変更しないことをお勧めします。
5. データベースに設定されたタイムゾーンが現在のコンソールのタイムゾーン（つまりブラウザのタイムゾーン）と一致していることを確認してください。または、データベースに設定されたタイムゾーンに対応する時間に換算してください。そうしないと、指定されたポイントの同期結果が期待どおりにならない可能性があります。
6. TDSQL MySQLの各クラスターノードの時刻が一致していることを確認してください。そうしないと、指定されたポイントの同期結果が期待どおりにならない可能性があります。
7. 設定された時点がXAトランザクションの継続時間の範囲内にある場合、そのXAトランザクションは同期されません。このような場合、時点を少し前に設定することをお勧めします（XA STARTの時刻より前）。
8. 指定時点機能を使用する場合、ソース側のgtid_modeはONに設定する必要があります。
列フィルタリング
1. PK、一意キーの列はフィルタリングをサポートしていません。システムはデフォルトでPK、一意キーの列をターゲット側に同期します。特別な状況でPK、一意キーがフィルタリングされた場合、事前検証でエラーが報告されます。
2. フィルタリングされた列が複合PK、外部キー、パーティション列である場合、またはフィルタリング列にインデックスが含まれている場合、ソース側はその列に対するDML操作をサポートしません。そうでない場合、タスクでエラーが報告される可能性があります。
3. 列フィルタリングとビューの相互作用の説明は以下の通りです：
3.1 同期オブジェクトでビューを選択した場合、ビュー関連列のデータを一緒に同期する必要があり、フィルタリングはできません。そうしないと、タスクでエラーが報告されます。
3.2 同期オブジェクトでビューを選択し、その後ソースデータベースがビューを作成する際に関連付けるのがシステムデータベース・テーブルである場合、同期タスクで同時に列フィルタリングを使用することはできません。そうしないと、タスクでエラーが報告されます。
4. 列フィルタリングを設定した後、同期設定の再変更はサポートされません。同期設定を変更する際も、列のフィルタリングはサポートされません。
5. テーブルAのX列に列フィルタリングを実行し、ユーザーがソース側でCREATE TABLE table_B like table_A文を実行する場合、テーブルBのX列にもフィルタリングを実行することをお勧めします。このシナリオでは、DTSによるテーブルBの同期は、テーブルAの列フィルタリング後のテーブル構造に従って行われます。テーブルBのX列にフィルタリングを実行していない場合、その後ソース側でテーブルBのX列のデータを更新する際に、同期タスクがエラーを報告します。
6. テーブルオブジェクト内の一意キー列に関数が含まれている場合、同期オブジェクトでそのテーブルを選択した際に、列の次元まで展開できず、列フィルタリングは実行できません。

ヘルプとサポート

この記事はお役に立ちましたか？

営業担当者にお問い合わせいただくかチケットを提出してサポートを求めることができます。

フィードバック

tencent cloud

Data Transfer Service

使用説明

ヘルプとサポート

カテゴリ	説明
同期オブジェクト	1. 基本テーブル、ビューの同期のみをサポートし、関数、トリガー、ストアドプロシージャなどのオブジェクトの同期はサポートしません。 2. 相互に関連するデータオブジェクトは同時に同期する必要があります。そうしないと、同期が失敗する可能性があります。 3. 増分同期段階では、ソースデータベースのテーブル名に「TDSQLagent」、「tdsql_sub」という文字が含まれている場合、フィルタリングされたり、同期異常を引き起こしたりする可能性があります。これらのテーブル名はTDSQLシステムの一時テーブル名と同じであるためです。TDSQLagentは拡張時の一時テーブルであり、tdsql_subテーブルはhash-lishおよびhash-rangeのサブテーブルです。したがって、ソース側で同期対象のテーブル名をこれらのタイプに設定しないことをお勧めします。
ソースデータベースへの影響	1. データ同期時、DTSは同期タスクを実行するアカウントを使用してソースデータベースにシステムデータベース`__tencentdb__`を書き込み、トランザクションマークIDなどのメタ情報を記録します。ソースデータベースにおける`__tencentdb__`への読み書き権限を確保する必要があります。後続のデータ比較問題を特定できるようにするため、同期タスク終了後もソースデータベース内の`__tencentdb__`は削除されません。 `__tencentdb__`システムデータベースが占有する容量は非常に小さく、ソースデータベースのストレージ容量の約1000分の1から1万分の1です（例えば、ソースデータベースが50GBの場合、`__tencentdb__`システムデータベースは約5MB～50MBです）。また、シングルスレッドと接続待機メカニズムを採用しているため、ソースデータベースのパフォーマンスにはほとんど影響を与えず、リソースを奪い合うこともありません。 2. デフォルトではロックフリー同期方式を採用し、フルデータエクスポート段階ではソースデータベースにグローバルロック（FTWRL）をかけず、主キーがないテーブルにのみテーブルロックをかけます。
ターゲット側 Kafka の要件	1. ターゲット側Kafkaのバージョンは、現在Tencent Cloudで購入可能なプロフェッショナル版とスタンダード版のみサポートされており、バージョン1.1.1以降が対象です。すでに販売終了となった物理マシンのスタンダード版はターゲット側としてサポートされていません。 2. ターゲットKafkaでメッセージ保持期間とメッセージサイズの上限を変更する必要があります。メッセージ保存期間は3日に設定することをお勧めします。保存期間を過ぎたデータは削除されます。ユーザーは設定した期間内に速やかに消費してください。メッセージサイズの上限、つまりKafkaが受信できる単一メッセージのメモリサイズは、ソースデータベースのテーブル内の単一行データの最大値より大きく設定する必要があります。これにより、ソースデータベースのデータがすべて正常にKafkaに配信されます。 3. ターゲットTopicは空にすることをお勧めします。また、同期タスク中は、ターゲット側で同期対象として選択したTopicにデータを書き込まないでください。そうしないと、メッセージの不整合やタスクエラーが発生する可能性があります。
データ同期の説明	1. InnoDB、MyISAM、TokuDBの3種類のデータベースエンジンのみ同期をサポートします。これら以外のデータエンジンテーブルが存在する場合、デフォルトでスキップされ同期されません。 2. 同じタスクは複数のTopicに関連付けることができますが、同じTopicを同時に複数の同期タスクで使用することはできません。そうしないと、データの不整合が発生し、消費されるデータが複数の異なるタスクのデータとなり、タスクの再試行などのシナリオでデータ処理の異常やタスクエラーが発生する可能性があります。 3. 全量同期段階では、10万件のデータを同期するごとに、ターゲット側Kafkaにcheckpointメッセージが1件挿入され、現在のデータ同期位置を示します。 4. DTSがターゲット側Kafkaに同期する単一メッセージには性能上限があります。ユーザーはソースデータベース内の単一行データを8MB以下に抑えることをお勧めします。そうしないと、同期中にエラーが発生する可能性があります。 5. ユーザーが同期中に特定のテーブルに対してrename操作を行うことが確実な場合、データはターゲットkafkaに配信され、パーティションルールは新しいテーブル名に基づいてtopicとpartitionをマッチングします。 6. 増分同期中に、ソースデータベースでSTATEMENT形式のBinlogステートメントが生成された場合、同期が失敗します。 7. ALTER VIEWステートメントはサポートされていません。このステートメントが検出された場合、タスクはスキップされ、同期されません。 8. ソース側インスタンス全体を選択しての同期はサポートされていません。後続の同期タスクで、ソース側に新しいデータベースを作成する操作（CREATE DATABASE）がある場合、同期タスクの開始前に、ターゲット側で該当するデータベースオブジェクトをあらかじめ作成することをお勧めします。 9. 同期タスクの進行中に、ソース側でCREATE TABLE、RENAME TABLEの操作が発生した場合、設定段階で同期オブジェクトを選択する際に、該当テーブルが属するデータベース全体を選択してください。そうしないと、新規作成されたテーブルやRENAME後のテーブルはターゲット側に同期されません。 10. 同期タスクがすでに開始されている場合、ユーザーがターゲット側Ckafkaのパーティション数を変更した後、タスクの再起動をトリガーする必要があります（先に一時停止してから再開することで再起動を実現します）。これにより、データは新しく追加されたパーティションに配信されます。
データ消費の説明	同期タスクの前に、ソースデータベースに既に存在する全量データは、データ書き込みの正確な時間がないため、コンシューマー側のデモではhappenAtフィールドが1970-01-01 08:00:00と表示されますが、この時間フィールドは気にする必要はありません。増分データを消費する際には、時間フィールドは正しく表示されます。
再起動の影響	同期タスク中に、タスクの再起動が発生した場合（ソースデータベースでHA切り替えが発生すると再起動し、バックグラウンドチェックでタスク異常が検出されると再起動します）、可能性があり、ターゲット側Kafkaに同期されるデータに重複が発生する可能性があります。 DTSは最小データユニット単位で同期を行います（全量段階では単一テーブルオブジェクトの1ブロックのデータが最小データユニットとなり、増分段階では1つのポジションがマークされるごとに1つのデータユニットとなります）。再起動時に、ちょうど1つのデータユニットの同期が完了している場合は、データの重複は発生しません。再起動時に、1つのデータユニットがまだ同期中である場合は、再度起動した後にこのデータユニットを再同期してデータの整合性を保つ必要があるため、データの重複が発生します。ユーザーが重複データを気にする場合は、データを消費する際に重複排除ロジックを設定してください。
操作制限	同期中に以下の操作を行わないでください。行うと同期タスクが失敗します。 1. フルエクスポート段階では、ソースデータベース上でデータベースまたはテーブル構造を変更するDDL操作を実行しないでください。 2. ソースデータベースおよびターゲット側のユーザー情報（ユーザー名、パスワード、権限を含む）とポート番号を変更、削除しないでください。 3. ソースデータベース上でBinlogを削除する操作を実行しないでください。
データ型	1. TDSQL MySQLをソースデータベースとして使用し、proxy方式で接続するシナリオでは、ソースデータベースでfloatデータ型を使用すると、フル段階のデータ精度が不正確になります。データ精度を保持する必要がある場合は、doubleデータ型の使用をお勧めします。フル段階の精度問題による具体的な影響は以下の通りです：フル段階と増分段階のデータ同期の精度が一致しません。 floatをキー値として使用する場合、フル段階と増分段階で操作されるPKデータが一致しません。 2. DTSは全量データ同期段階で、ソースデータベースのデータをエクスポートし、ターゲット側Kafkaにインポートします。いずれもutf8mb4文字セットを使用し、文字セットが認識されないことによる文字化けを防ぎます。 3. Geometry関連のデータ型はサポートされていません。このタイプのデータが検出された場合、タスクはエラーを報告します。
トランザクション	1つのトランザクションにDML文とDDL文が同時に含まれるシナリオはサポートされていません。この状況が発生すると、タスクはエラーを報告します。
HA切り替えと拡張	1. ソースデータベースが非GTIDデータベースの場合、DTSはソース側のHA切り替えをサポートしません。ソース側のTDSQL MySQLで切り替えが発生すると、DTSの増分同期が中断される可能性があります。 2. DTSがSETでTDSQL MySQLに直接接続するシナリオでは、TDSQL MySQLの拡張はサポートされません。ProxyでTDSQL MySQLに接続するシナリオでは、TDSQL MySQLの論理拡張がサポートされます。水平拡張時にDTSがエラーを報告する可能性があります。
パーティションテーブル同期	1. プライマリ/セカンダリパーティションテーブルの構文は仕様に準拠する必要があります。プライマリHashパーティションテーブルは、shardkey方式でのみ作成できます。 TDSQL MySQLでパーティションテーブルを作成するための主要な構文は以下のとおりです。詳細な構文については、TDSQL MySQL公式ドキュメントを参照してください。 1.1 プライマリパーティションプライマリHashパーティション：shardkey プライマリRangeパーティション：TDSQL_DISTRIBUTED BY RANGE プライマリListパーティション：TDSQL_DISTRIBUTED BY LIST 1.2 セカンダリパーティションプライマリHashパーティション+セカンダリRange/Listパーティション：shardkey + PARTITION BY RANGE/LIST プライマリRangeパーティション+セカンダリRange/Listパーティション：TDSQL_DISTRIBUTED BY RANGE + PARTITION BY RANGE/LIST プライマリListパーティション+セカンダリRange/Listパーティション：TDSQL_DISTRIBUTED BY LIST + PARTITION BY RANGE/LIST 1.3 新規セカンダリパーティションプライマリHashパーティション+セカンダリRange/Listパーティション：TDSQL_DISTRIBUTED BY HASH + TDSQL_PARTITION BY RANGE/LIST 2. 増分同期段階では、並行DDL操作はサポートされていません。前のDDLが有効になってから次のDDLを実行する必要があります。そうしないと、DDLの順序乱れによってエラーが発生する可能性があります。また、同じ名前のテーブルに対してcreate、drop、create操作を迅速に実行することもサポートされていません。そうしないと、テーブルタイプエラーが発生する可能性があります。
開始位置の指定	初期化タイプをいずれもチェックしない場合、増分同期のみを実行することを示し、増分同期の開始位置を設定できます。現在、この機能を使用するにはチケットを提出して申請する必要があります。 1. 増分同期タスクは、設定された時点からデータの同期を開始します。設定可能な時点の範囲は、過去14日間から現在時刻までです。 2. 全量同期と増分同期を2つのタスクに分けて実行する場合、増分同期を実行する際には、DTSがすでに同期した全量データの時点1と設定した時点2の間に、DDL（CREATE TABLE、ALTER TABLE、DROP TABLE、RENAME TABLE、CREATE INDEX、DROP INDEX）によるデータ変更が存在してはなりません。存在する場合、タスクはエラーを報告します。 3. 設定された指定時点1から増分タスクの開始時点2までの間（タスクステップが「指定ポイントの検索」から「増分同期」に移行した時点で開始とみなされます）、ソースデータベース操作の注意事項は以下の通りです。ソースデータベースでは、マスタースレーブ切り替え、シャードの追加、スタンバイ機の再作成を行わないことをお勧めします。そうしないと、DTSがソースデータベースのGTIDポジションを取得する際に影響が出る可能性があります。ソース側は同期オブジェクトに関係のないDDLを操作できますが、前のDDLがターゲット側に同期された後に新しいDDLを実行することを保証する必要があります。DDLを集中的に実行すると、タスクエラーが発生する可能性があります。ソース側では同期オブジェクトに関係するDDL（CREATE TABLE、ALTER TABLE、DROP TABLE、RENAME TABLE、CREATE INDEX、DROP INDEX）を操作することはできません。そうしないと、同期タスクがエラーを報告します。 4. 指定時点同期はBinlog内のcontextの時間（SET TIMESTAMP=XXXX）に基づいてそのGTIDを判断するため、同期データの正確性を保証するために、ユーザーがこのcontextを変更しないことをお勧めします。 5. データベースに設定されたタイムゾーンが現在のコンソールのタイムゾーン（つまりブラウザのタイムゾーン）と一致していることを確認してください。または、データベースに設定されたタイムゾーンに対応する時間に換算してください。そうしないと、指定されたポイントの同期結果が期待どおりにならない可能性があります。 6. TDSQL MySQLの各クラスターノードの時刻が一致していることを確認してください。そうしないと、指定されたポイントの同期結果が期待どおりにならない可能性があります。 7. 設定された時点がXAトランザクションの継続時間の範囲内にある場合、そのXAトランザクションは同期されません。このような場合、時点を少し前に設定することをお勧めします（XA STARTの時刻より前）。 8. 指定時点機能を使用する場合、ソース側のgtid_modeはONに設定する必要があります。
列フィルタリング	1. PK、一意キーの列はフィルタリングをサポートしていません。システムはデフォルトでPK、一意キーの列をターゲット側に同期します。特別な状況でPK、一意キーがフィルタリングされた場合、事前検証でエラーが報告されます。 2. フィルタリングされた列が複合PK、外部キー、パーティション列である場合、またはフィルタリング列にインデックスが含まれている場合、ソース側はその列に対するDML操作をサポートしません。そうでない場合、タスクでエラーが報告される可能性があります。 3. 列フィルタリングとビューの相互作用の説明は以下の通りです： 3.1 同期オブジェクトでビューを選択した場合、ビュー関連列のデータを一緒に同期する必要があり、フィルタリングはできません。そうしないと、タスクでエラーが報告されます。 3.2 同期オブジェクトでビューを選択し、その後ソースデータベースがビューを作成する際に関連付けるのがシステムデータベース・テーブルである場合、同期タスクで同時に列フィルタリングを使用することはできません。そうしないと、タスクでエラーが報告されます。 4. 列フィルタリングを設定した後、同期設定の再変更はサポートされません。同期設定を変更する際も、列のフィルタリングはサポートされません。 5. テーブルAのX列に列フィルタリングを実行し、ユーザーがソース側でCREATE TABLE table_B like table_A文を実行する場合、テーブルBのX列にもフィルタリングを実行することをお勧めします。このシナリオでは、DTSによるテーブルBの同期は、テーブルAの列フィルタリング後のテーブル構造に従って行われます。テーブルBのX列にフィルタリングを実行していない場合、その後ソース側でテーブルBのX列のデータを更新する際に、同期タスクがエラーを報告します。 6. テーブルオブジェクト内の一意キー列に関数が含まれている場合、同期オブジェクトでそのテーブルを選択した際に、列の次元まで展開できず、列フィルタリングは実行できません。