tiflow
tiflow copied to clipboard
pingcap
syncer(dm): Add unit test and integration test for multi-schema change when encountering "invalid connection" error
What problem does this PR solve?
Issue Number: ref #4689
What is changed and how it works?
I have added unit test and integration test for multi-schema change when encountering "invalid connection" error, as additional tests for #6848. The running results have proved that the current logic works correctly for the multi-schema change situation as well.
According to experiments, the behavior of DM and TiDB is slightly different for multi-schema change.
Suppose we execute ALTER TABLE gbk.invalid_conn_test2 MODIFY i SMALLINT NOT NULL DEFAULT '0', MODIFY j SMALLINT NOT NULL DEFAULT '0' in DM and manually in TiDB separately.
For DM:
mysql> ADMIN SHOW DDL JOBS;
+--------+---------+--------------------+-----------------------------------+--------------+-----------+----------+-----------+---------------------+---------------------+---------------------+--------+
| JOB_ID | DB_NAME | TABLE_NAME | JOB_TYPE | SCHEMA_STATE | SCHEMA_ID | TABLE_ID | ROW_COUNT | CREATE_TIME | START_TIME | END_TIME | STATE |
+--------+---------+--------------------+-----------------------------------+--------------+-----------+----------+-----------+---------------------+---------------------+---------------------+--------+
| 1140 | gbk | invalid_conn_test2 | modify column | public | 1102 | 1135 | 0 | 2022-09-15 19:13:25 | 2022-09-15 19:13:25 | 2022-09-15 19:13:27 | synced |
| 1139 | gbk | invalid_conn_test2 | modify column | public | 1102 | 1135 | 0 | 2022-09-15 19:13:22 | 2022-09-15 19:13:22 | 2022-09-15 19:13:25 | synced |
| ... |
+--------+---------+--------------------+-----------------------------------+--------------+-----------+----------+-----------+---------------------+---------------------+---------------------+--------+
10 rows in set (0.01 sec)
mysql> ADMIN SHOW DDL JOB QUERIES LIMIT 10 OFFSET 0;
+--------+----------------------------------------------------------------------------------------------------------------------------------------+
| JOB_ID | QUERY |
+--------+----------------------------------------------------------------------------------------------------------------------------------------+
| 1140 | ALTER TABLE `gbk`.`invalid_conn_test2` MODIFY COLUMN `j` SMALLINT(4) NOT NULL DEFAULT '0' |
| 1139 | ALTER TABLE `gbk`.`invalid_conn_test2` MODIFY COLUMN `i` SMALLINT(4) NOT NULL DEFAULT '0' |
| ... |
+--------+----------------------------------------------------------------------------------------------------------------------------------------+
10 rows in set (0.00 sec)
The multi-schema change DDL would be separated into two or more single DDL, and are executed by order one by one.
For manually operated in TiDB:
mysql> ADMIN SHOW DDL JOBS;
+--------+------------------+--------------------+---------------------------------+--------------+-----------+----------+-----------+---------------------+---------------------+---------------------+---------------+
| JOB_ID | DB_NAME | TABLE_NAME | JOB_TYPE | SCHEMA_STATE | SCHEMA_ID | TABLE_ID | ROW_COUNT | CREATE_TIME | START_TIME | END_TIME | STATE |
+--------+------------------+--------------------+---------------------------------+--------------+-----------+----------+-----------+---------------------+---------------------+---------------------+---------------+
| 2273 | gbk | invalid_conn_test2 | alter table multi-schema change | none | 2204 | 2271 | 0 | 2022-09-16 19:43:36 | 2022-09-16 19:43:36 | 2022-09-16 19:43:43 | synced |
| 2273 | gbk | invalid_conn_test2 | modify column /* subjob */ | public | 2204 | 2271 | 0 | NULL | NULL | NULL | done |
| 2273 | gbk | invalid_conn_test2 | modify column /* subjob */ | public | 2204 | 2271 | 0 | NULL | NULL | NULL | done |
| ... |
+--------+------------------+--------------------+---------------------------------+--------------+-----------+----------+-----------+---------------------+---------------------+---------------------+---------------+
18 rows in set (0.01 sec)
mysql> ADMIN SHOW DDL JOB QUERIES LIMIT 10 OFFSET 0;
+--------+-------------------------------------------------------------------------------------------------------------------+
| JOB_ID | QUERY |
+--------+-------------------------------------------------------------------------------------------------------------------+
| 2273 | ALTER TABLE gbk.invalid_conn_test2 MODIFY i SMALLINT NOT NULL DEFAULT '0', MODIFY j SMALLINT NOT NULL DEFAULT '0' |
| ... |
+--------+-------------------------------------------------------------------------------------------------------------------+
10 rows in set (0.01 sec)
The multi-schema change DDL would be separated into two or more subjob. The history returned by ADMIN SHOW DDL JOBS would contain both the subjobs and the original multi-schema change job. The history returned by ADMIN SHOW DDL JOB QUERIES LIMIT 10 OFFSET 0 would only contain the original multi-schema change job but not the subjobs.
I have added a unit test to test the manual TiDB situations since other unit tests have already covered the DM situations. I have added several integration tests to test the DM situations.
Check List
Tests
- Unit test
- Integration test
Questions
Will it cause performance regression or break compatibility?
No.
Do you need to update user documentation, design documentation or monitoring documentation?
No.
Release note
Fix the issue that dm-worker keeps retrying to execute ddl for every 5 minutes when encountering "invalid connection" error (works for multi-schema change as well).
[REVIEW NOTIFICATION]
This pull request has been approved by:
- GMHDBJD
- lance6716
To complete the pull request process, please ask the reviewers in the list to review by filling /cc @reviewer in the comment.
After your PR has acquired the required number of LGTMs, you can assign this pull request to the committer in the list by filling /assign @committer in the comment to help you merge this pull request.
The full list of commands accepted by this bot can be found here.
Reviewer can indicate their review by submitting an approval review. Reviewer can cancel approval by submitting a request changes review.
Codecov Report
Merging #7104 (93b3f4f) into master (f4754e1) will increase coverage by
6.0358%. The diff coverage is9.8039%.
Additional details and impacted files
| Flag | Coverage Δ | |
|---|---|---|
| cdc | 67.5551% <ø> (+0.1075%) |
:arrow_up: |
| dm | ? |
|
| engine | 60.9629% <9.8039%> (-0.0056%) |
:arrow_down: |
Flags with carried forward coverage won't be shown. Click here to find out more.
@@ Coverage Diff @@
## master #7104 +/- ##
================================================
+ Coverage 59.8150% 65.8508% +6.0358%
================================================
Files 803 565 -238
Lines 92129 52218 -39911
================================================
- Hits 55107 34386 -20721
+ Misses 32213 15171 -17042
+ Partials 4809 2661 -2148
This pull request has been accepted and is ready to merge.
This pull request has been accepted and is ready to merge.
@lyzx2001: Your PR was out of date, I have automatically updated it for you.
At the same time I will also trigger all tests for you:
/run-all-tests
If the CI test fails, you just re-trigger the test that failed and the bot will merge the PR for you after the CI passes.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the ti-community-infra/tichi repository.