カテゴリ | 説明 |
同期オブジェクト | 1. 基本テーブル、ビューの同期のみをサポートし、関数、トリガー、ストアドプロシージャなどのオブジェクトの同期はサポートしません。 2. 相互に関連するデータオブジェクトは同時に同期する必要があります。そうしないと、同期が失敗する可能性があります。 3. ソース側のTDSQL MySQLではテーブル数に制限があり、インスタンス全体で最大5000個です。これを超えるとDTSタスクがエラーを報告します。また、テーブル数が多すぎるとソース側のアクセス時間が長くなり、パフォーマンスのジッターや低下を引き起こします。 4. 増分同期段階では、ソースデータベースのテーブル名に「TDSQLagent」、「tdsql_sub」という文字が含まれている場合、フィルタリングされたり、同期異常を引き起こしたりする可能性があります。これらのテーブル名はTDSQLシステムの一時テーブル名と同じであるためです。TDSQLagentは拡張時の一時テーブルであり、tdsql_subテーブルはhash-listおよびhash-rangeのサブテーブルです。したがって、ソース側で同期対象のテーブル名をこれらのタイプに設定しないことをお勧めします。 |
ソースデータベースへの影響 | 1. DTSはフルデータ同期を実行する際に、一定のソースデータベースリソースを占有し、ソースデータベースの負荷上昇を引き起こし、データベース自体の圧力を高める可能性があります。データベースの設定が低すぎる場合は、ビジネスのオフピーク期に実行することをお勧めします。 2. データ同期時、DTSは同期タスクを実行するアカウントを使用してソースデータベースにシステムデータベース __tencentdb__を書き込み、トランザクションマークIDなどのメタ情報を記録します。ソースデータベースにおける__tencentdb__への読み書き権限を確保する必要があります。後続のデータ比較問題を特定できるようにするため、同期タスク終了後もソースデータベース内の __tencentdb__は削除されません。__tencentdb__システムデータベースが占有する容量は非常に小さく、ソースデータベースのストレージ容量の約1000分の1から1万分の1です（例えば、ソースデータベースが50GBの場合、__tencentdb__システムデータベースは約5MB～50MBです）。また、シングルスレッドと接続待機メカニズムを採用しているため、ソースデータベースのパフォーマンスにはほとんど影響を与えず、リソースを奪い合うこともありません。3. デフォルトではロックフリー同期方式を採用し、フルデータエクスポート段階ではソースデータベースにグローバルロック（FTWRL）をかけず、主キーがないテーブルにのみテーブルロックをかけます。 |
同期機能の説明 | 1. 現在のPK競合処理ポリシーは競合上書きのみをサポートしており、フルおよび増分段階のPKデータ競合はすべて競合上書きが行われます。 2. DDLの操作制約は以下の通りです： フルエクスポート段階では、ソースデータベース上でデータベースまたはテーブル構造を変更するDDL操作を実行しないでください。 同期増分段階において、TDSQL MySQL分散型をソースとするリンクで、ソース側がDDLを実行する際、短時間に大量の同時実行を行わないことをお勧めします。リンクの遅延や中断を引き起こす可能性があります。 3. InnoDBデータベースエンジンのみ同期をサポートします。他のデータエンジンテーブルが存在する場合、タスク検証時にエラーが報告されます。 4. 増分同期中は主キーの変更をサポートしていません。主キー列、パーティションテーブルの分散キー、主キー列に対するCOMMENT注釈、列フィールドと長さの追加・削除・変更が含まれます。 5. 増分同期中に、ソースデータベースでSTATEMENT形式のBinlogステートメントが生成された場合、同期が失敗します。 6. ソース側インスタンス全体を選択しての同期はサポートされていません。後続の同期タスクで、ソース側に新しいデータベースを作成する操作（CREATE DATABASE）がある場合、同期タスクの開始前に、ターゲット側で該当するデータベースオブジェクトをあらかじめ作成することをお勧めします。 7. 同期タスクの進行中に、ソース側でCREATE TABLE、RENAME TABLEの操作が発生した場合、設定段階で同期オブジェクトを選択する際に、該当テーブルが属するデータベース全体を選択してください。そうしないと、新規作成されたテーブルやRENAME後のテーブルはターゲット側に同期されません。 |
操作制限 | 同期中に以下の操作を行わないでください。行うと同期タスクが失敗します。 1. 同期タスクの進行中は、ソースデータベースとターゲットデータベース内のユーザー情報（ユーザー名、パスワード、権限を含む）とポート番号を変更、削除しないでください。 2. ソースデータベース上でBinlogを削除する操作を実行しないでください。 |
データ型 | 1. Geometry関連のデータ型はサポートされていません。このタイプのデータが検出された場合、タスクはエラーを報告します。 2. 浮動小数点タイプが存在するテーブルでは、フル同期と増分同期の精度に差異があるため、同期結果の精度が一致しない可能性があります。 3. ソース側のTDSQL MySQLがMariaDB 10.1.xカーネルの場合、timestamp型は精度の指定をサポートしていません（例：timestamp(3)）。指定した場合、DTSタスクがエラーを報告するため、精度を削除してからタスクを再作成する必要があります。 |
トランザクション | 1. 1つのトランザクションにDML文とDDL文が同時に含まれるシナリオはサポートされていません。この状況が発生した場合、タスクはエラーを報告します。 2. ソースデータベースがTDSQL MySQL（カーネルMariaDB 5.6）の場合、XAトランザクションはサポートされていません。XAトランザクションが発生すると、タスクはエラーを報告します。 |
HA切り替えと拡張 | 1. ソースデータベースが非GTIDデータベースの場合、DTSはソース側のHA切り替えをサポートしません。ソース側のTDSQL MySQLで切り替えが発生すると、DTSの増分同期が中断される可能性があります。 2. ソースデータベースが自己構築データベースで、SETを使用してTDSQL MySQLに接続するシナリオの場合、同期タスクの開始後に、ソース側でSETノードの追加または削除が行われると、DTS同期タスクはエラーを報告します。ユーザーはDTS内のソースデータベースのSET設定情報を変更し（ソース側の実際のSETと一致させる）、その後タスクを再起動する必要があります。これにより、追加または削除されたSETの情報を同期できます。 |
パーティションテーブル同期 | 1. フル同期段階では、プライマリ/セカンダリパーティションテーブルの同期をサポートしています。ただし、パーティション構文はTDSQL MySQLの仕様に準拠する必要があります。プライマリHashパーティションテーブルは、shardkey方式でのみ作成できます。 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. 増分同期段階では、セカンダリパーティションテーブルの密集したcreate、その後のdrop、さらにその後のcreateという操作はサポートされていません。そうしないと、テーブルタイプの競合によりタスクが異常になる可能性があります。存在しないセカンダリパーティションテーブルを先にdropし、その後createすると、デッドロックが発生する可能性があり、タスクにエラーは表示されず、手動でロックを解除する必要があります。 3. TDSQL MySQLからMySQL/MariaDB/Perconaへの同期リンクでは、ソース側の同期対象データベース・テーブルにセカンダリパーティションテーブルが含まれている場合、ターゲット側に同期された後は単一テーブルになります。 |
開始位置の指定 | 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に設定する必要があります。 |
Was this page helpful?
You can also Contact sales or Submit a Ticket for help.
Help us improve! Rate your documentation experience in 5 mins.
Feedback