fix data-integrity: timestamp convert to datetime scenario #969
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Fixed merge conflict for testing |
dm-2
previously approved these changes
Jul 6, 2022
timvaillancourt
approved these changes
Jul 6, 2022
|
@cenkore / @dm-2 / @rashiq: as this converts data I'd like to be very sure it works now and in the future Are there any tests that we can add to the
|
timvaillancourt
requested changes
Jul 6, 2022
@timvaillancourt Sorry for taking a long time to reply you. PTAL. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
related: #161 #247 #269 ..
This PR is to fix the data integrity problem in timestamp conversion datetime scenarios.
Env
Reason
The timestamp time_zone parsed from binlog is CST +08:00, go-sql-driver will convert it to UTC +00:00 by default, and finally when applying to the database, even though add session query
set @@session.time_zone='+00:00', but because the column type has been changed to datetime, the time zone did not do conversion again, so the time zone was actually only converted by half, causing the data written to _xx_gho is 8 hours smaller.Solution
In this case, change the time zone from +00:00 to the local system time zone, which is the opposite of datetime convert to timestamp.
Thank you !