一般的な問題
DTSを使用したデータ移行・同期は、ソースデータベースにどのような影響がありますか？
1. ソースデータベースのデータ内容に影響はなく、ソースデータベースは正常に業務書き込みを行うことができます。DTSはデータ移行時に、実際にはソースデータベースのデータをコピーするものであり、ソースデータベースの内容を削除することはないため、ソースデータベースのデータに影響はありません。
2. ソースデータベースのパフォーマンスに一定の影響があり、影響は主にCPUにあります。
DTSはフルデータ移行/同期を実行する際に、ソースデータベースの全データを一度読み取るため、ソースデータベース自体の負荷が増加します。
ソースデータベースがMySQL、スペックが8コア16Gの場合を例にとると、DTSタスクはデフォルトで8スレッドの並行処理を採用します。ネットワークにボトルネックがない場合、DTSタスクがソースデータベースに与える性能影響は以下の通りです：
DTSフルエクスポート段階：ソースデータベースのCPUを約18%～45%占有し、ソースデータベースに約40～60MB/sのクエリ負荷を増加させ、約8個のアクティブsession接続数を占有します。
DTS増分エクスポート段階：ソースデータベースにほぼ負荷をかけず、1つの接続のみがソースデータベースのbinlogログをリアルタイムで監視します。
3. フルエクスポート段階におけるソースデータベースの各接続の詳細。
3.1 （オプション）チャンク段階。ソースデータベーステーブルの推定行数が200万行未満の場合はチャンク分割を行いません。200万行を超える場合はチャンク分割が必要となり、以下の接続が追加されます。
ソースデータベーステーブルの主キーは整数型であり、かつほぼ連続しているため、以下のような少量のSQLが発生します。
`SELECT MIN(`id`), MAX(`id`) FROM `db`.`table`
ソースデータベーステーブルの主キーが文字列または不連続な整数型の場合、以下のようなSQLが発生します。ORDER BY `id` limit文はソースデータベースへの負荷をわずかに増加させます。DTSはデフォルトで3スレッドを使用し、同時にソースデータベースのスペックに応じて調整することで、ソース側への負荷を制御可能な範囲に保ちます。
SELECT `id` FROM `db`.`table` WHERE `id` > `某个id` ORDER BY `id` limit 500000, 1
3.2 タスクがエクスポート段階を開始すると、1つのスレッドがシステムテーブルをクエリしてエクスポート情報を取得します。これにより、以下のようなSQLが発生します。
SELECT TABLE_NAME, TABLE_TYPE, ENGINE, TABLE_ROWS FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='db'
SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS WHERE ABLE_SCHEMA='db' and TABLE_NAME='table' and CONSTRAINT_TYPE='PRIMARY KEY';
3.3 構造エクスポート段階では、エクスポートスレッド数（デフォルト8）の接続が以下のSQLを実行します。
SELECT COLUMN_NAME, DATA_TYPE, COLUMN_TYPE, NUMERIC_PRECISION, NUMERIC_SCALE, CHARACTER_SET_NAME, COLUMN_DEFAULT, IS_NULLABLE from information_schema.COLUMNS "
"where TABLE_SCHEMA='db' and TABLE_NAME='db';
3.4 データエクスポート段階では、エクスポートスレッド数（デフォルト8）の接続が以下のSQLを実行します。
SELECT /*!40001 SQL_NO_CACHE */ column FROM db.table where id>= 'id' AND id <
'id';
3.5 ロックフリーエクスポート時には、以下のようなテーブルロックSQLが発生します。テーブルロックは主キーなしテーブルの一貫性ポイントを取得するためだけに行われ、取得後すぐにロックが解除されます。
3.6 ロックありエクスポート時には、以下のSQLのようなグローバルロックが発生します。
flush table xxx with read lock
DTSを使用したデータ移行・同期は、ターゲットデータベースにどのような影響がありますか？
全量段階で、DTSがターゲットデータベースに書き込む際、ターゲットデータベースへの主な影響はCPUとIOPSにあります。
ソースデータベースがMySQLで、スペックが8コア16Gの場合、DTSタスクはデフォルトで8スレッドの並行処理を採用します。ネットワークにボトルネックがない場合、DTSフルインポート段階がターゲットデータベースに与える性能影響は以下の通りです：ターゲットデータベースのCPUを約20%～49%占有し、IOPSを約1200～3100占有し、アクティブsession接続数を8未満占有します。
全量段階におけるターゲットデータベースの接続詳細は以下の通りです：
8未満の接続が構造を一括作成しています。
8未満の接続がデータを一括書き込みしています。類似のSQLは以下の通りです：
insert into xxx (id,name,msg) values (xxx);
増分段階では、DTSがソースデータベースのbinlog内の増分データをSQLに解析し、その後ターゲットデータベースで実行します。総接続数は32セッション未満です。その内訳は以下の通りです：
DDLは直列に実行されます。DDLの実行中は、他のDMLは実行されません。
DMLには最大32の接続があります（すべて短時間接続で、タイムアウト時間は30秒です）。そのうちDMLは単純なinsert、update、delete、replace文のみです。
DTSを使用したデータ移行では、ターゲットデータベースは空である必要がありますか？
データをターゲットデータベースに移行する際、インスタンス全体を移行するか、指定したオブジェクトを移行するかを選択できます。
インスタンス全体の移行：ターゲットデータベースが空である必要があります。事前にターゲットデータベースをクリアしてください。空でない場合、システム検証に合格せず、タスクを開始できません。
指定オブジェクトの移行：指定したデータベース、テーブルなどのオブジェクトを選択して移行します。システムがソースデータベースとターゲットデータベースに同名のデータベース・テーブルがあるかどうかを検証し、ある場合は検証に合格せず、ユーザーに変更を促してから移行タスクを実行します。
DTSはソースデータベースが読み取り専用インスタンスを使用した移行をサポートしていますか？
サポートされています。ソースデータベースが自己構築データベースの場合、DTSがソースデータベースに接続する設定で、読み取り専用インスタンスのIPを入力するだけで済みます。ソースデータベースがTencent Cloudのクラウドデータベースインスタンスの場合、移行とサブスクリプションの両方で読み取り専用インスタンスへの接続がサポートされています。なお、サブスクリプションについてはチケットを提出して申請する必要があります。
DTSはソースデータベースがスタンバイデータベースを使用した移行をサポートしていますか？
ソースデータベースが自己構築データベースの場合、DTSがソースデータベースに接続する設定で、スタンバイデータベースのIPを入力するだけで済みます。ソースデータベースがTencent Cloudデータベースインスタンスの場合、DTSがソースデータベースに接続する設定で、インスタンスIDのみを選択でき、スタンバイデータベースには接続できません。
データ移行中にソースデータベースへの書き込みはサポートされていますか？
サポートされています。移行プロセス中、ソースデータベースへのデータ書き込みは正常に行えますが、構造移行および全量移行の段階では、ソースデータベースに対してDDL操作を実行できません。実行した場合、タスクが失敗する可能性があります。増分移行の段階になると、DDLとDMLの両方を正常に操作できます。
データ移行中にターゲットデータベースへの書き込みはサポートされていますか？
ターゲットデータベースを読み取り専用に設定する必要はありませんが、ターゲットデータベースへの書き込みは行わないことをお勧めします。移行プロセス中にユーザーが同時にターゲットデータベースに書き込むと、最終的にソースとターゲットのデータが一致しなくなる可能性があります。
DTSは両端ともオフラインライブラリである移行をサポートしていますか？
サポートされていません。ソース側またはターゲット側のいずれかがTencent Cloudデータベースである必要があります。
DTSは、2つの異なるTencent CloudアカウントにあるTencentDBインスタンス間のデータ移行をサポートしていますか？
サポートされています。異なるTencent CloudアカウントのTencentDBインスタンス間の移行を行うには、ターゲットTencentDBインスタンスが属するTencent CloudアカウントでDTSにログインする必要があります。具体的な操作については、クラウドデータベースのアカウント間インスタンス移行を参照してください。 DTSは同一データベースインスタンス内の異なるデータベース・テーブル間の移行をサポートしていますか？
サポートされていません。DTSは、ソースデータベースとターゲットデータベースが異なるデータベースインスタンス間のデータ移行のみをサポートしています。ソースデータベースとターゲットデータベースが同一のデータベースインスタンスである場合（同一データベースインスタンス内の異なるデータベース・テーブルオブジェクトの移行）はサポートされていません。
同じソースデータベースで、複数のDTSタスクを設定し、異なるクラウドデータベースインスタンスへ移行することはサポートされていますか？
サポートされています。同じソース側から複数のターゲット側への移行（タスクは並列処理可能）、および複数のソース側から同じターゲット側への移行（前のタスクが増分段階に進んでから新しいタスクを開始する必要があります）がサポートされています。複数のタスクを並列実行すると、ソース側またはターゲット側のアクセス負荷が増加し、移行速度に影響を与える可能性があることに注意してください。同じソースデータベースに対して複数のタスクを作成する必要がある場合は、最初の移行タスクを作成した後、操作列の詳細 > 類似タスクの作成から、同じタスクをすばやく作成できます。
DTSは定時自動移行をサポートしていますか？
サポートされています。DTSを作成した後、設定を変更する際に、スケジュール実行のオプションを選択し、スケジュール移行時間を設定できます。
移行中にタスクの進捗を監視できますか？
はい、Tencent CloudのDTSコンソールデータ移行ページで移行タスクの進捗を確認できます。 データ増分移行サービスに15日間の設定があるのはなぜですか？
データ増分移行サービスは現在、最寄りのプロキシサーバーを介して接続しています。プライベートネットワーク専用線を通じて、パブリックネットワーク経由のジッター問題を低減し、データ転送の品質を確保しています。15日間の設定は、プロキシサーバーの接続負荷を効果的に低減するためのものです。15日を超えた場合でも、現段階では強制的に切断されることはなく、移行リソースの合理的な使用の観点から時間設定の規定を設けているだけです。
データ移行中に、データの正確性をどのように保証しますか？
DTS内部ではTencent Cloudが自社開発したデータ移行アーキテクチャを採用し、伝送リンクに対してリアルタイムでデータの正確性検証を行い、伝送データの問題を迅速に検出して修正し、データ伝送の信頼性を保証します。
データ検証にソースデータベースインスタンスが読み取り専用でないことが必要なのはなぜですか？
データ検証では、ソースインスタンスに新しいデータベース__tencentdb__を作成し、そのデータベースにCheckSumテーブルを書き込む必要があります。そのインスタンスが読み取り専用の場合、データ検証段階はスキップされます。
DTSデータ移行では、データベース・テーブルを指定して移行できますか？
はい、移行オブジェクトとしてインスタンス全体を選択することも、指定したデータベース・テーブルオブジェクトを選択することもできます。
データ移行はいつ終了しますか？
ユーザーが増分移行を選択した場合、タスクが長時間終了しないことがあり、その場合はユーザー自身が終了操作を行う必要があります。
移行タイプとして構造移行または全量移行を選択した場合、タスク完了後に自動的に終了するため、ユーザーが手動で終了する必要はありません。
移行タイプとして全量+増分移行を選択した場合、全量移行の完了後、自動的に増分データ同期段階に入ります。増分データ同期は自動的に終了しないため、手動で「完了」をクリックして増分データ同期を終了する必要があります。
適切なタイミングを選択して手動で増分データ同期を完了し、ビジネス切り替えを完了してください。
移行段階が増分同期であり、遅延がない状態であることを確認し、ソースデータベースへの書き込みを数分間停止します。
ターゲットとソースデータベースのデータ差異が0MB、かつターゲットとソースデータベースの時間遅延が0秒の場合、手動で増分同期を完了します。
全量移行前後でデータサイズが一致しないのはなぜですか？
ソースデータベースとターゲットデータベースのフラグメンテーション領域が異なるため、ソースデータベースに一部の空きデータが存在する可能性があります。そのため、全量移行の完了後、ターゲットデータベースのテーブルストレージ領域はソースデータベースのテーブルストレージ領域よりも小さくなる可能性が高くなります。移行の完了後、データ一貫性の検証を使用して、ソースデータベースとターゲットデータベースの内容が一致しているかどうかを確認することをお勧めします。 DTSデータ転送サービスは、国境を越えたデータベース移行をサポートしていますか？
サポートされています。アクセス方式としてパブリックネットワークを選択すると、国境を越えたデータ転送を実現できます。
DTS移行中にタスクが異常中断した場合、再起動できますか？
はい、ユーザーはタスクを設定する際に自動再試行ポリシーを設定できます。タスクに異常中断が発生した場合（ソースデータベースやターゲットデータベースの一時的な利用不可、ネットワーク問題など）、DTSは設定された時間範囲内で自動再試行をサポートしており、手動介入は不要です。
MySQLのよくある質問
MySQL移行中にロックは発生しますか？
MySQL移行中のロックとは、ソースデータベースにグローバルロック（FTWRL）をかけることを指します。全量データ移行を選択した場合にのみ、ロック処理が発生します。
現在のDTSは、MySQL/MariaDB/Percona/TDSQL-C MySQL/TDSQL MySQL/TDSQL TDStore間のデータ移行において、デフォルトでロック不要の移行を使用します。ロック不要の移行とは、ソースデータベースにグローバルロック（FTWRL）をかけず、PKのないテーブルにのみテーブルロックをかけることを指します。
主キーなしテーブルの移行はサポートされていますか？
サポートされています。ただし、PKのあるテーブルを選択することをお勧めします。PKのないテーブルでもタスクを開始できますが、以下の影響が生じます：
PKのないテーブルの移行/同期を行うと、データが重複する可能性があります。
PKのないテーブルにDML操作が行われると、データ同期の遅延が発生しやすくなります。
データ一貫性の検証を行う際、PKのないテーブルはスキップされ、検証はサポートされません。
ソースデータベースがAlibaba Cloud RDS、PolarDBの場合、RDS、PolarDBはBinlog内でPKのないテーブルまたはNULLでない一意キーのないテーブルに追加のPK列を付与しますが、テーブル構造には表示されません。そのため、DTSが認識できず、データ結果が異常になる可能性があります。
Tencent Cloud MySQLシングルノード（旧基本版）インスタンスの移行はサポートされていますか？
Tencent Cloud MySQLシングルノード（旧ベーシック版）はソースとしてパブリックネットワークモードで移行できますが、プライベートネットワークモードは使用できません。
現在、Tencent Cloud MySQLシングルノード（旧ベーシック版）を移行のターゲットインスタンスとして使用することはサポートされていません。
binlog_formatをrowに設定した後、現在のデータベース上のすべての業務接続をリセットする必要があります（ソースデータベースがスレーブにある場合、マスタースレーブ同期SQLスレッドもリセットする必要があります）。現在の業務接続が古いフォーマットで書き込みを続けることを防ぎます。
上記の操作が終了する前に、移行タスクを作成または開始しないでください。データの不一致が発生するのを防ぐためです。
移行元インスタンスにTokuエンジンが含まれている場合、移行時に注意すべき点は何ですか？
ソースインスタンスにTokuエンジンが含まれている場合、移行時にデフォルトでInnoDBに変換します。その後、Cluster IndexとTokuDBの圧縮特性を持つテーブルは事前に処理する必要があります。現在、移行はサポートされていません。また、Tokuエンジンに対するDDL操作も移行ではサポートされていません。
MySQLデータ移行でユーザー権限を移行できますか？
サポートされています。新しいバージョンのDTSはユーザー権限の移行をサポートしています。具体的な操作については、アカウント移行を参照してください。