このトピックでは、Global Database Network (GDN) のプライマリインスタンスとセカンダリインスタンスのデータを検証する方法について説明します。
前提条件
GDNが作成され、少なくとも1つのセカンダリインスタンスがGDNに追加されます。 詳細については、「GDNの作成と管理」をご参照ください。
使用上の注意
このトピックで説明する操作は、セカンダリインスタンスでのみ実行できます。
データ検証タスクはストレージリソースを消費します。 オフピーク時にデータ検証タスクを実行することを推奨します。
データ検証タスクの送信
構文
CHECK REPLICA TABLE {`test_db`.`test_tb`} | {`test_db`} [CHANNEL='channel_name'] [MODE=direct|snapshot];
制限事項
主キーのないテーブルは検証できません。
検証中のテーブルに対して新しいデータ検証タスクを送信すると、データ検証タスクは無視されます。
検証済みのテーブルに対して新しいデータ検証タスクを送信すると、最後のタスクで生成されたテーブルの検証結果が、新しいタスクで生成された結果に置き換えられます。
データ検証タスクは、非同期的に実行される。
タスクを送信して、指定したデータベース内の単一のテーブルまたはすべてのテーブルを検証できます。
構文では、
CHANNEL
パラメーターはセカンダリインスタンスの現在のチャネル名を示します。 セカンダリインスタンスでSHOW SLAVE STATUS
ステートメントを実行し、Channel_Name
の値を表示することで、パラメーター値を取得できます。 詳細については、「ショースラブステータス」をご参照ください。構文では、
MODE
は検証モードを示します。 有効な値:snapshot
: アップストリームデータとダウンストリームデータの整合性スナップショットを作成してデータを検証します。 この値をMODEに指定するには、同期ポイント
機能を有効にする必要があります。 詳細については、「同期ポイントの有効化」をご参照ください。direct
: アップストリームデータとダウンストリームデータを直接読み取り、データを検証します。 このモードでの検証結果は不正確である可能性があります。
例
mysql> check replica table `testdb`.`testtb` channel='test' mode=direct;
Query OK, 0 rows affected (0.05 sec)
同期ポイントの有効化
同期ポイント機能を有効にするには、プライマリインスタンスで次のSQL文を実行します。
set global enable_polarx_sync_point = true;
set global enable_sync_point = true;
set global enable_xa_tso = true;
set global enable_auto_commit_tso = true;
# Specify the interval at which sync points are generated. Unit: millisecond.
set global SYNC_POINT_TASK_INTERVAL = 5000;
同期ポイント機能を有効にすると、変更データキャプチャ (CDC) ノードは、データ同期中にプライマリインスタンスとセカンダリインスタンス間のTSOマッピングをリアルタイムで構築します。 すべてのTSOマッピングは、セカンダリインスタンスのinformation_schema.rpl_sync_point
ビューで表示できます。
mysql> select * from information_schema.rpl_sync_point limit 10;
+-------+---------------------+---------------------+---------------------+
| ID | PRIMARY_TSO | SECONDARY_TSO | CREATE_TIME |
+-------+---------------------+---------------------+---------------------+
| 31482 | 7211850887478640704 | 7211850889504489536 | 2024-06-27 06:00:41 |
| 31483 | 7211850908445966400 | 7211850910203379776 | 2024-06-27 06:00:46 |
| 31484 | 7211850929417486400 | 7211850931690799168 | 2024-06-27 06:00:51 |
| 31485 | 7211850950393200704 | 7211850952322580544 | 2024-06-27 06:00:56 |
| 31486 | 7211850971368915008 | 7211850973738696768 | 2024-06-27 06:01:01 |
| 31487 | 7211850992327852096 | 7211850994282397760 | 2024-06-27 06:01:06 |
| 31488 | 7211851013303566400 | 7211851015677542464 | 2024-06-27 06:01:11 |
| 31489 | 7211851034275086400 | 7211851036204466240 | 2024-06-27 06:01:16 |
| 31490 | 7211851055250800704 | 7211851057595416640 | 2024-06-27 06:01:21 |
| 31491 | 7211851076218126400 | 7211851078210420800 | 2024-06-27 06:01:26 |
+-------+---------------------+---------------------+---------------------+
10 rows in set (0.04 sec)
TSOは、バイナリログ内のトランザクションを一意に識別するために使用されるタイムスタンプです。 詳細については、「Simple Log Service (バイナリログ) 」をご参照ください。
TSOマッピングは、同じ時点における一次インスタンスおよび二次インスタンスのTSOを含む。
データ検証タスクの進行状況の表示
構文
CHECK REPLICA TABLE {`test_db`.`test_tb`} | {`test_db`} SHOW PROGRESS;
指定したデータベース内の単一のテーブルまたはすべてのテーブルのデータ検証の進行状況を表示できます。
例:
mysql> CHECK REPLICA TABLE `test_db`.`test_tb` SHOW PROGRESS;
+----------+---------+-------+----------+---------+
| DATABASE | TABLE | STAGE | STATUS | SUMMARY |
+----------+---------+-------+----------+---------+
| test_db | test_tb | CHECK | FINISHED | SUCCESS |
+----------+---------+-------+----------+---------+
1 row in set (0.04 sec)
データ検証タスクの一時停止
構文
CHECK REPLICA TABLE {`test_db`.`test_tb`} | {`test_db`} PAUSE;
各テーブルのデータ検証タスクは、タスクに含まれるデータのサイズに基づいて1つ以上のサブタスクに自動的に分割されます。 SQL文を実行してデータ検証タスクを一時停止した後、タスクの進行中のすべてのサブタスクは引き続き実行され、開始されていないサブタスクは一時停止されます。
例:
mysql> CHECK REPLICA TABLE `testdb`.`testtb` PAUSE;
Query OK, 0 rows affected (0.05 sec)
一時停止したデータ検証タスクを続行する
構文
CHECK REPLICA TABLE {`test_db`.`test_tb`} | {`test_db`} CONTINUE;
一時停止データ検証タスクを続行すると、タスクのすべての一時停止サブタスクの実行が開始されます。
例:
mysql> CHECK REPLICA TABLE `testdb`.`testtb` CONTINUE;
Query OK, 0 rows affected (0.05 sec)
データ検証タスクの結果を表示する
構文
CHECK REPLICA TABLE {`test_db`.`test_tb`} | {`test_db`} SHOW DIFF;
例:
mysql> CHECK REPLICA TABLE `test_db`.`test_tb` SHOW DIFF;
+----------+---------+------------+--------+--------------+-------------+--------------+-------------+
| DATABASE | TABLE | ERROR_TYPE | STATUS | SRC_KEY_NAME | SRC_KEY_VAL | DST_KEY_NAME | DST_KEY_VAL |
+----------+---------+------------+--------+--------------+-------------+--------------+-------------+
| test_db | test_tb | Miss | FOUND | [id] | [2] | [id] | NULL |
+----------+---------+------------+--------+--------------+-------------+--------------+-------------+
1 row in set (0.00 sec)
結果のERROR_TYPE
フィールドは、アップストリームとダウンストリームのデータが一致しない理由を示します。 有効な値:
Miss: ダウンストリームで一部のデータが欠落しています。
Orphan: 追加のデータは下流に含まれています。
Diff: アップストリームデータとダウンストリームデータが異なります。
データ検証タスクの削除
構文
CHECK REPLICA TABLE {`test_db`.`test_tb`} | {`test_db`} CANCEL;
データ検証タスクを削除すると、そのタスクによって生成されたすべての結果も消去されます。
例:
mysql> CHECK REPLICA TABLE `testdb`.`testtb` CANCEL;
Query OK, 0 rows affected (0.05 sec)