Skip to content
This repository has been archived by the owner on Nov 24, 2023. It is now read-only.

loader, syncer: Update sql_mode to more compatible #1869

Merged
merged 18 commits into from
Jul 20, 2021

Conversation

okJiang
Copy link
Member

@okJiang okJiang commented Jul 14, 2021

What problem does this PR solve?

close #1735 and #1818

What is changed and how it works?

By add/delete some upstream's global.sql_mode to make downstream's sql_mode more compatible.

Check List

Tests

  • Integration test

Code changes

Side effects

Related changes

okJiang added 2 commits July 14, 2021 11:40
* update load.go/syncer.go with modifying sql_mode,
* add sql_mode Integration Test
@CLAassistant
Copy link

CLAassistant commented Jul 14, 2021

CLA assistant check
All committers have signed the CLA.

Copy link
Collaborator

@lance6716 lance6716 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also notice there're two usage of SQL mode: one to execute SQLs and one to parse upstream DDLs

@glorv glorv added the needs-cherry-pick-release-2.0 This PR should be cherry-picked to release-2.0. Remove this label after cherry-picked to release-2.0 label Jul 14, 2021
@glorv glorv added this to the v2.0.5 milestone Jul 14, 2021
@lance6716 lance6716 added the needs-update-release-note This PR should be added into release notes. Remove this label once the release notes are updated label Jul 14, 2021
@glorv
Copy link
Collaborator

glorv commented Jul 14, 2021

/run-all-tests

@glorv
Copy link
Collaborator

glorv commented Jul 14, 2021

Integration test handle_error failed by:

[2021-07-14T10:22:13.455Z] got=0 expected=2

[2021-07-14T10:22:13.456Z] command: query-status test Error .*: Incorrect int value count: 0 != expected: 2, failed the 9-th time, will retry again

@okJiang Seems after we remove STRICT_TRANS_TABLES from sql_mode, this will cause insert with invalid value to succeed instead of failed, which is expected. So https://github.com/pingcap/dm/blob/master/tests/handle_error/run.sh#L20-L38 this test will failed.

But In the original test case, the insert fails because upstream change column type but downstream (tidb) don't support this, so after skip ddl, the insert should fail bacuase data in not fit in downstream anymore.

@GMHDBJD @lance6716 @kennytm PTAL at this case, I think we should still keep the STRICT_TRANS_TABLES and all user to manually set sql_mode e.g. to just remove STRICT_TRANS_TABLES if needed.

@glorv
Copy link
Collaborator

glorv commented Jul 15, 2021

Integration test handle_error failed by:

[2021-07-14T10:22:13.455Z] got=0 expected=2

[2021-07-14T10:22:13.456Z] command: query-status test Error .*: Incorrect int value count: 0 != expected: 2, failed the 9-th time, will retry again

@okJiang Seems after we remove STRICT_TRANS_TABLES from sql_mode, this will cause insert with invalid value to succeed instead of failed, which is expected. So https://github.com/pingcap/dm/blob/master/tests/handle_error/run.sh#L20-L38 this test will failed.

But In the original test case, the insert fails because upstream change column type but downstream (tidb) don't support this, so after skip ddl, the insert should fail bacuase data in not fit in downstream anymore.

@GMHDBJD @lance6716 @kennytm PTAL at this case, I think we should still keep the STRICT_TRANS_TABLES and all user to manually set sql_mode e.g. to just remove STRICT_TRANS_TABLES if needed.

I rethought about this, If data have been successfully inserted in the upstream, it must be valid even if the origin value may not be. So I think we should always enable STRICT_TRANS_TABLES to avoid ignoring this kind of bad data.

@GMHDBJD
Copy link
Collaborator

GMHDBJD commented Jul 15, 2021

I rethought about this, If data have been successfully inserted in the upstream, it must be valid even if the origin value may not be. So I think we should always enable STRICT_TRANS_TABLES to avoid ignoring this kind of bad data.

@glorv I think we should keep STRICT_TRANS_TABLES consistent with upstream, and allow users to specify it.
If the user removes STRICT_TRANS_TABLES in upstream but keeps it downstream, some data may be invalid when replicating to downstream. https://asktug.com/t/topic/63881

@okJiang
Copy link
Member Author

okJiang commented Jul 15, 2021

Integration test handle_error failed by:

[2021-07-14T10:22:13.455Z] got=0 expected=2

[2021-07-14T10:22:13.456Z] command: query-status test Error .*: Incorrect int value count: 0 != expected: 2, failed the 9-th time, will retry again

@okJiang Seems after we remove STRICT_TRANS_TABLES from sql_mode, this will cause insert with invalid value to succeed instead of failed, which is expected. So master/tests/handle_error/run.sh#L20-L38 this test will failed.
But In the original test case, the insert fails because upstream change column type but downstream (tidb) don't support this, so after skip ddl, the insert should fail bacuase data in not fit in downstream anymore.
@GMHDBJD @lance6716 @kennytm PTAL at this case, I think we should still keep the STRICT_TRANS_TABLES and all user to manually set sql_mode e.g. to just remove STRICT_TRANS_TABLES if needed.

I rethought about this, If data have been successfully inserted in the upstream, it must be valid even if the origin value may not be. So I think we should always enable STRICT_TRANS_TABLES to avoid ignoring this kind of bad data.

But once always enable STRICT_TRANS_TABLES, most of the work we do is meaningless. Because

Strict mode affects handling of division by zero, zero dates, and zeros in dates
https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sql-mode-strict

And at the beginning we wanted to solve the problem that user insert invalid datetime #1735.

@lance6716
Copy link
Collaborator

lance6716 commented Jul 15, 2021

not catch up with your discussion, I just want to remind the data may be inserted in a session SQL mode that is different with global SQL mode

@okJiang
Copy link
Member Author

okJiang commented Jul 15, 2021

/run-all-tests

Copy link
Contributor

@lichunzhu lichunzhu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@ti-chi-bot ti-chi-bot added status/LGT1 One reviewer already commented LGTM needs-rebase labels Jul 16, 2021
@okJiang
Copy link
Member Author

okJiang commented Jul 19, 2021

/run-all-tests

@okJiang
Copy link
Member Author

okJiang commented Jul 19, 2021

PTAL @lance6716 @GMHDBJD

Copy link
Collaborator

@lance6716 lance6716 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rest lgtm

);

-- test sql_mode PIPES_AS_CONCAT
insert into t_1(num) values('pipes'||'as'||'concat');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why this can be inserted into an int field 😂

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because it exists here as a bit operation OR.

-- test sql_mode NO_AUTO_VALUE_ON_ZERO
insert into t_1(id, name) values (10, 'a');
insert into t_1(id, name) values (0, 'b');
insert into t_1(id, name) values (0, 'c');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since we didn't set sql mode in this SQL file, above two insert are converted to auto increment value, so the binlog is writtern with the auto increment value not zero, and this didn't test DM will add NO_AUTO_VALUE_ON_ZERO with AdjustSQLModeCompatible

since db2 (source2) has done this test, maybe we could remove above lines.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think it just tested what you said above.

@ti-chi-bot
Copy link
Member

[REVIEW NOTIFICATION]

This pull request has been approved by:

  • lance6716
  • lichunzhu

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.

@ti-chi-bot ti-chi-bot added status/LGT2 Two reviewers already commented LGTM, ready for merge and removed status/LGT1 One reviewer already commented LGTM labels Jul 20, 2021
@lance6716
Copy link
Collaborator

/run-all-tests

2 similar comments
@okJiang
Copy link
Member Author

okJiang commented Jul 20, 2021

/run-all-tests

@glorv
Copy link
Collaborator

glorv commented Jul 20, 2021

/run-all-tests

@glorv
Copy link
Collaborator

glorv commented Jul 20, 2021

/merge

@ti-chi-bot
Copy link
Member

This pull request has been accepted and is ready to merge.

Commit hash: d436f23

@ti-chi-bot ti-chi-bot merged commit caad97b into pingcap:master Jul 20, 2021
ti-chi-bot pushed a commit to ti-chi-bot/dm that referenced this pull request Jul 20, 2021
Signed-off-by: ti-chi-bot <ti-community-prow-bot@tidb.io>
@ti-chi-bot
Copy link
Member

In response to a cherrypick label: new pull request created: #1894.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
first-time-contributor needs-cherry-pick-release-2.0 This PR should be cherry-picked to release-2.0. Remove this label after cherry-picked to release-2.0 needs-update-release-note This PR should be added into release notes. Remove this label once the release notes are updated size/XL status/can-merge status/LGT2 Two reviewers already commented LGTM, ready for merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.

SQL mode is still not automatic enough
8 participants