データ整合性チェックの作成（MySQL系）
ダウンロード
フォーカスモード
フォントサイズ
操作シナリオ
データ一貫性の検証、つまりDTSがデータ移行のソースデータベースとターゲットデータベースのテーブルデータを比較し、比較結果と不一致の詳細を提供することで、ユーザーが切り替え前に同期結果を迅速に検証できるようにします。データ一貫性の検証タスクは独立して実行され、ソースデータベースの通常業務に影響を与えず、DTSのタスクにも影響を与えません。
説明：
一貫性の検証は、補助的なデータ検証手段としてのみ使用されます。正式な切り替え前に、ユーザー自身でリハーサル操作を行い、結果が切り替え要件を満たしていることを確認してください。
独立検証、組み込み検証、GTID検証の違い
一貫性の検証は、独立検証、組み込み検証、GTID検証の3つの検証方式に分かれており、ユーザーは実際のニーズに応じて選択できます。
比較項目 | 組み込み検証 | 独立検証 | GTID検証 |
定義 | 検証サービスはDTSタスクに内蔵されており、タスクの実行中に一貫性の検証を開始する必要があります。DTSタスクの実行が停止された後は、検証の開始はサポートされていません。 | 検証サービスはDTSタスクから独立しており、ソース側とターゲット側の同じデータブロックを選択して比較します。DTSタスクの実行が停止された後は、検証の開始はサポートされていません。 | ソース側とターゲット側で実行されたGTIDに基づいて、データの一貫性を比較します。 |
リンクサポート | MySQL/MariaDB/Percona/TDSQL-C MySQL/TDSQL Boundless/TDSQL MySQLの移行、同期リンク。 | MySQL/MariaDB/Percona/TDSQL-C MySQL/TDSQL Boundlessの移行、同期リンク。 | MySQL/MariaDB/Percona/TDSQL-C MySQL/TDSQL Boundlessの移行、同期リンク。 |
比較範囲 | DTSタスクで選択された移行オブジェクトのみを比較し、ソースデータベースで選択されていない移行オブジェクトは検証範囲に含まれません。 DTSによってターゲット側に書き込まれたデータのみを比較し、ユーザー自身がターゲット側に書き込んだデータは検証範囲に含まれません。 | DTSタスクで選択されていない他の移行オブジェクトを比較できます。 ユーザーが自らターゲット側に書き込んだデータを比較できます。 | すべての移行対象を比較します。 |
検証中の要件 | ソース側にはDMLデータの書き込みが可能ですが、DDLデータの書き込みはできません。そうでない場合、検証が不正確になる可能性があります。 | 静的データ状態で検証を開始することをお勧めします。つまり、ソース側とターゲット側の両方でデータ書き込みがない状態です。そうでない場合、検証結果が不正確になる可能性があります。 | ソース側とターゲット側の両方でGTID機能を有効にする必要があります。 |
注意事項および制約事項
1. データ一貫性検証タスクはソースデータベースインスタンスの負荷を増加させる可能性があります。そのため、業務の低ピーク時に操作を行ってください。
2. 比較検証の制約事項：
完全検証、サンプリング検証：PKなし／一意キーなしのテーブルの場合、行数が5万行未満のときは検証をサポートし、5万行を超えるテーブルは検証をスキップします。
行数検証：PKまたは一意キーの存在は必須ではありません。
3. 現在の検証タスクはDDL操作を認識しません。移行中にユーザーがソースデータベースに対してDDL操作を行った場合、検証結果に不一致が生じます。正確な比較結果を得るには、ユーザーが検証タスクを再度開始する必要があります。
4. 一貫性の検証タスクにおいて、DTSがソースまたはターゲット側のデータを1回クエリする際のタイムアウト制限は10分です。1回のクエリとは、各チャンク検証で1回クエリすること、行検証で1回クエリすることなどを指します。1回のクエリ時間が10分を超えた場合（例えば、ソース側でクエリするテーブルが大きいテーブルの場合）、検証タスクが失敗します。
5. 内蔵検証の注意事項。
5.1 内蔵検証の範囲は、ソースデータベースで選択したテーブルオブジェクトとターゲットデータベースに移行したテーブルオブジェクトのみを比較します。ユーザーが移行タスク中にターゲットデータベースにデータを書き込んだ場合、そのデータは検証範囲に含まれず、その他の高度なオブジェクト（ストアドプロシージャ、関数など）、ビュー、アカウントも含まれません。
5.2 データ一貫性検証タスクがまだ終了していない時に、ユーザーがDTSタスクの完了または終了を選択した場合、データ一貫性検証タスクは失敗します。
5.3 一貫性の検証では、ソースデータベースに新しいデータベース
__tencentdb__を作成し、そのデータベースにChecksumテーブルを書き込む必要があるため、ソースデータベースが読み取り専用の場合は一貫性の検証がスキップされます。6. 独立検証の制約事項。
同期リンクでテーブルの名前変更を設定している場合：独立検証を行う際に、検証対象で「カスタムオブジェクト」を選択した場合、検証対象を選択するときにテーブルオブジェクトを1つずつ選択する必要があります。データベース全体を選択することはできません。そうしないと、以前に名前変更を行ったテーブルは検証がスキップされます。
実装原理
組み込み検証
DTSによるMySQL系データベースの一貫性の検証は、rowモード（binlog_format = row）に基づいています。rowモードは、masterとslaveの正確なレプリケーションを実現し、データの安全性を確保します。
実現原理は以下の通りです：
1. ソースデータベースに検証データベース
__tencentdb__.Checksumsを作成し、移行タスク中にデータ比較情報を保存するために使用します。2. 検証対象テーブルの非NULL一意キーを検証固定フィールドとして選択します。
3. ソースデータベースの検証値crc1と行数count1を計算し、ソースデータベースの
__tencentdb__.Checksumsに書き込みます。crcの計算方法はチャンク検証に類似しています。検証固定フィールドに基づいて、固定範囲（例えば、テーブルAから主キーが1～1000のデータを選択）を選択し、これらのデータを行ごとに連結して1つのcrcを計算します。これにより、各チャンクデータから1つのcrcが得られ、同時にソースデータベース全体のデータを計算してcrc1が得られます。
4. DTSはbinlog内のrowモードデータを解析し、ソースデータベースに検証値を書き込むSQLを復元し、そのSQLをターゲットデータベースで再生します。
ターゲットデータベース上でソースデータベースと同じ変数を使用して検証値と行数を計算し、ターゲットデータベースのcrc2とcount2を取得します。
5. ソースとターゲットデータベースの検証値と行数を比較し、比較結果を表示します。
独立検証
独立検証は、DTSデータ移行タスクに依存せず、独立して実行できるデータ比較ツールです。ユーザー定義の設定ファイルに基づいて、ソース側とターゲット側のデータを同時並行でクエリしてデータ比較を行います。異種データベース間でのデータ比較をサポートするために、異なるデータベースのデータを統一された型マッピングルールに従って変換します。また、データ比較の並列度を高め、データ同期遅延の影響を可能な限り排除するために、各テーブルをシャードに分割します。各データシャードは、データ比較における最小のデータクエリおよび処理単位です。
実現原理は以下の通りです：
1. 設定解析：主に、今回のデータ比較タスクに関連するデータベーステーブルの識別、名前変更ルールの処理、Where条件の設定などが含まれます。独立検証は、ユーザーがインスタンス全体、データベース全体、カスタムデータベース・テーブルなどのさまざまなオブジェクトを設定してデータ比較を行うことをサポートし、テーブルや列の許可リストと拒否リストの設定をサポートします。また、データベース、テーブル、列名に対するrename変換ルールの設定や、各テーブルへのWhereフィルタ条件の設定などもサポートします。さまざまな設定を通じて、ユーザーは自身のニーズに応じて適切なオブジェクトを選択し、データ比較を行うことができます。
2. テーブル構造解析：主に列名と列タイプの解析、文字セットと照合順序のクエリ、主キーと非NULL一意キーのクエリなどのステップが含まれます。主キーがなく、非NULL一意キーもないテーブルの場合、行数が5w行以下のとき、独立検証はデータ値に対してCRC計算を行うことでテーブルデータの一貫性を比較します。データの一意な識別子を見つけられないため、これらのテーブルでは正確な不一致行データを出力できず、訂正SQLも出力できません。行数が5w行を超える場合は、これらのテーブルのデータ比較をスキップします。列タイプ解析は異種環境において非常に重要です。統一された型マッピングルールに基づいて、異なるデータソース間のデータを同じメモリデータ型に変換します。列タイプ解析はこの重要なステップの基盤となります。
3. データシャード：データクエリとデータ比較の並列度を高めるために、独立検証はテーブルデータをシャードに分割します。各データシャードは、データクエリとデータ比較を行う最小単位でもあります。
MySQLタイプのデータベースでは、独立検証は主キー順序に基づく分割スライス戦略を採用しています。これは、MySQLがB+ツリーというデータ構造でデータを編成しており、主キーに基づく範囲クエリによって効率が向上し、最小限のI/O消費を実現できるためです。独立検証が使用する典型的なデータスライスアルゴリズムは以下の通りです：テーブルの主キーの最小値、最大値、および主キー順序に基づいて、そのテーブルのすべての主キー値を走査し、毎回固定のchunkSizeでスライスの上下境界値（つまり主キー値）をクエリし、これによって1つのデータスライスの範囲を決定します。独立検証はさらに、スライスプロセス全体を最適化するために多段階並列戦略を採用しています。まず、シャードまたはパーティションが存在するデータテーブルの場合、そのデータはシャードとパーティションに基づいて複数のデータセグメントに分割され、スライスの並列度が向上します。次に、1つのデータセグメント内でも、双方向接近戦略を採用し、先頭と末尾の両端から並列にデータスライスを行います。
4. データ比較：主にデータクエリ、データ型変換、データの一貫性比較が含まれます。データ型変換はこの段階の重要なステップです。異種データベースには列タイプのさまざまな差異が存在するため、異種データベースのデータ比較を行う前に、事前に定義された型マッピングルールに基づいて、異なるデータベースの列タイプを標準のメモリデータ型に変換します。同時に、このプロセスでは異種データベース間の文字セットエンコーディングの差異、時間タイプおよび範囲の差異、浮動小数点精度の差異なども処理し、これらのデータ比較の正確性を確保します。独立検証は主キーまたは一意キーに基づいて、各行のデータが一致しているかを比較します。不一致のデータについては、具体的なデータフィールドのデータ差異とクエリSQLを出力し、ユーザーが迅速にデータを特定できるようにします。同時に、独立検証は不一致データに対して訂正SQLを生成し、ユーザーがデータを修復できるようにします。
GTID検証
GTID（Global Transaction Identifier）は、MySQLでトランザクションを一意に識別するためのメカニズムです。GTID検証を通じて、ソースデータベースとターゲットデータベースのデータが一致しているかを迅速に検出し、比較結果と不一致の詳細を提供することで、ユーザーが同期結果を迅速に検証するのを支援します。GTID検証タスクは独立して実行され、ソースデータベースの通常の業務に影響を与えません。
実現原理は以下の通りです：
1. ソース側とターゲット側のデータベースで実行済みのGTID SETをそれぞれ取得します。
2. ソース側のGTID SETとターゲット側のGTID SETの差集合を計算し、ターゲット側で未実行のトランザクションを識別します。
3. 不一致のGTID範囲を分析し、対応するデータベース・テーブルの変更情報を関連付けます。
4. 不一致のGTID範囲および関連するデータベース・テーブル変更の詳細を出力します。
データ整合性チェックタスクの作成
自動トリガー
DTS移行タスクを新規作成する際に、データ一貫性の検証タスクを有効にできます。後続のタスクが同期増分ステップに進むと、一貫性の検証タスクが自動的に1回トリガーされます。
一貫性の検証の設定ページで、データ一貫性の検証を有効にするにチェックを入れ、パラメータを設定した後、次へをクリックします。
説明：
検証オプション
設定項目 | 説明 |
検証内容 | フル検証：ソースデータベースで移行対象として選択したすべてのオブジェクトデータを1件ずつ比較し、移行データの整合性を確保します。 |
検証基準 | 両端：ソース側とターゲット側のデータを検証基準として使用します。 |
パラメータの設定を検証
設定項目 | 説明 |
スレッド数選択 | 設定範囲は1～8です。実際の状況に応じて選択してください。スレッド数を増やすと一貫性の検証速度を向上させることができますが、ソースとターゲットデータベースの負荷も増加します。 |
再チェック回数 | 再チェック回数を設定します。 初回のフルデータ検証結果が不一致の場合、バックグラウンドでフル検証の不一致データに対して検証を開始します。 |
再チェック間隔 | 再チェック間隔を設定します。 |
検証対象オプション
設定項目 | 説明 |
検証対象 | すべての移行オブジェクト：検証範囲は移行タスクで選択されたすべてのオブジェクトです。 カスタム選択：選択した移行オブジェクトの中から、検証を行うオブジェクトを選択します。 |
手動作成
既存のDTS移行タスクに対して、データ一貫性の検証タスクを作成できます。
1. DTSコンソールにログインします。
2. データ移行ページで、検証が必要な移行タスクを選択し、操作列でその他 > データ一貫性の検証を作成を選択します。
説明：
データ一貫性の検証は、移行タスクのステップが同期増分に進んだ時点でのみ作成できます。インターフェースのボタンがグレー表示の場合、DTSタスクの状態が条件を満たしていません。例えば、タスクが同期増分ステップに進んでいない、タスクが失敗した、タスクが終了したなどです。
3. データ一貫性の検証ページで、データ一貫性の検証を作成をクリックします。
説明：
既に一貫性の検証タスクが存在する場合は、操作列の類似タスクを作成をクリックでき、関連パラメータの設定もサポートされます。
4. ポップアップダイアログでデータ一貫性の検証パラメータを設定した後、一貫性の検証を作成して開始をクリックします。
パラメータ | 説明 |
タスク名 | 一貫性検証タスクを作成するための名前。 |
検証方式 | 独立検証：検証サービスはDTSタスクとは独立しており、ソース側とターゲット側の同じデータブロックを選択して比較します。DTSタスクの実行が停止した後は、検証の開始はサポートされません。 内置検証：検証サービスはDTSタスクに内蔵されており、タスクの実行中に一貫性の検証を開始する必要があります。DTSタスクの実行が停止した後は、検証の開始はサポートされません。 GTID検証：ソース側とターゲット側で実行されたGTIDに基づいてデータの一貫性を比較します。各移行タスクには、GTID検証タスクを1つだけ関連付けることができます。 |
検証内容 | フル検証：ソースデータベースで同期対象として選択したすべてのオブジェクトデータを1件ずつ比較し、移行データの整合性を確保します。 |
検証タイプ | 完全検証：選択した検証対象の完全なデータを検証します。 サンプリング検証：選択した検証対象から一定の割合を抽出して検証します。 行数検証：選択した検証対象について、データ行数のみを比較します。行数比較を選択した場合、テーブルオブジェクトにPKは必須ではなく、PKなしのテーブルでも検証を実行できます。 |
サンプリング割合 | サンプリング割合を設定します。サンプリング割合は10%、20%、30%……90%をサポートします。 説明： 検証タイプがサンプリング検証の場合のみ、このパラメータを設定する必要があります。 |
検証対象 | すべての移行オブジェクト：検証範囲は移行タスクで選択されたすべてのオブジェクトです。 カスタム選択：選択した移行オブジェクトの中から、検証を行うオブジェクトを選択します。 |
スレッド数選択 | 設定範囲は1～8です。実際の状況に応じて選択してください。スレッド数を増やすと一貫性の検証速度を向上させることができますが、ソースとターゲットデータベースの負荷も増加します。 |
再チェック回数 | 再チェック回数を設定します。 初回のフルデータ検証結果が不一致の場合、バックグラウンドでフル検証の不一致データに対して検証を開始します。 |
再チェック間隔 | 再チェック間隔を設定します。 |
データ整合性チェック結果の表示
1. 移行タスクのホームページで、最後の検証結果列から検証結果を確認できます。一致または不一致の場合、詳細を見るをクリックして検証詳細ページに移動します。
2. 表示をクリックすると、検証結果を確認できます。
3. 検証結果を確認します。
独立検証、内蔵検証
推定テーブル総数、検証済みテーブル数、不一致テーブル数、スキップ済みテーブル数を確認します。
推定テーブル総数：検証予定のテーブル総数の推定値であり、最終的な実際の検証テーブル総数とは若干の差異が生じる場合があります。正確な推定テーブル総数を提供すると、全体の検証パフォーマンスに影響するためです。
未チェックテーブルの理由：PKまたは非NULL一意キーがない、空テーブル、サポートされていないエンジンタイプ、テーブルが存在しない。
GTID検証
ソース側とターゲット側の差分、ソース側とターゲット側の不一致データベース・テーブル、ターゲット側とソース側の差分を確認します。
4. 不一致の詳細を確認します。
内蔵検証のシナリオでは、不一致の結果に対して、ユーザーがソースデータベースとターゲットデータベースの対応する内容を手動で比較する必要があります。
画面に表示されるデータベース、データテーブル、インデックス名、インデックス上限、インデックス下限のパラメータに従って、具体的な位置を特定して比較してください。
参考操作は以下の通りです：
1. ソースデータベースにログインし、提示されたインデックス範囲をクエリします。select * from table_name where col_index >=1 and col_index <=5;2. ターゲットデータベースにログインし、提示されたインデックス範囲をクエリします。3. ターゲットとソースのデータ差異を比較します。
独立検証のシナリオ
4.1.1 検出済みエリアで該当テーブルの後ろにある表示をクリックすると、不一致のデータ詳細を確認できます。
4.1.2 表示されたダイアログボックスで不一致の詳細を確認します。
4.1.3 操作列で訂正文をクリックします。
訂正文を表示します。
4.1.4 ダイアログボックスの右側で
不一致情報と訂正文をダウンロードするか、または訂正文のみをダウンロードできます。
GTID検証のシナリオ
不一致の詳細エリアで、不一致のデータ詳細を確認できます。
5. 比較結果の詳細をダウンロードします。
5.1 検証進捗ページで、右側の
5.2 表示されたダイアログボックスで、ダウンロードをクリックします。
フィードバック