-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding test to validate JSON reported issue #19
base: master
Are you sure you want to change the base?
Conversation
Signed-off-by: Shlomi Noach <[email protected]>
Hmmm sadly the tests pass and do not reproduce the error depicted in github#976 @derekPNM would you like to verify the tests introduced here are legit? |
Signed-off-by: Shlomi Noach <[email protected]>
Either the test is not representative enough, or this could be a Amazon Aurora problem (issue reports |
Hi Shlomi - The tests appear legit, to the best of my knowledge. For clarification - gh-ost is running while those sql statements are being executed? We'll look into upgrading our Aurora version, and I'll try to replicate locally using mysql 5.7..32 (to gather more information). |
We are unable to replicate this issue against mysql 5.7.32 running the recent OSX distribution of gh-ost. We've even updated Aurora to 2.10 to no avail. This does seem to be related to Aurora binlog formats. We'll be running a few more experiments to share with the community (in the event that someone else eventually will benefit). Thank you. |
That is correct. The migration runs for (at least) 5 seoncds, during which an event issues those |
Appreciate your efforts in pinning down the issue! Assuming the tests would fail, my thought was to update to latest https://github.com/go-mysql-org/go-mysql, which may still solve your issue, I just don't know. |
Would it be difficult to get a test build of gh-ost with the latest version of go-mysql? That might help. At this point we are looking into refactoring our code to not leverage a virtual json-in-json column |
@shlomi-noach We dove deep into this and got the 16.4 version of go on our system, and built an executable for gh-ost following the instructions. We aren't sure if we did this correctly (go is new to us) , as we continue to see the error. We were wondering, however, should we be using to use a different version of go-mysql instead of the bundled version?
Specifically we wonder about this line? Any thoughts? |
@derekPNM sorry was sidetracked with other stuff. |
Thank you kindly. We appreciate your help. |
Let's see how #22 goes |
Artifact generated here: https://github.com/openark/gh-ost/suites/2923311567/artifacts/65612096 |
Assuming that artifact is for us to test with... when trying to execute our script we receive the following error:
|
Yep!
Seems completely unrelated to the new build? What is the command you're trying to run? |
specifically, do you have |
I noticed something similar happened with the related PR that Here's the command (same command we've been using since we encountered the binlog issue, BTW): for _tbl in reference_table do gh-ost done ` The configuration file has only a client section, and has the username and password for connecting to the database. |
OK maybe
I hope this doesn't just push to the next validation error. 🤞 |
Thank you. It pushed us to the next validation error :( . I'll keep on working my way through them to see if the new go-mysql helps. In the meantime: github#935 (comment) |
We needed to add max_lag_millis to proceed: Unfortunately we are receiving the same types of errors (but with more information):
|
Hi Shlomi, We appreciate your help on this issue we've stumbled across. At this point we think it "best" for us to remove the json-in-json virtual columns we are using with Aurora. If the gh-ost team ever wants to revisit this issue, just let me know and I can try to reproduce it in our environment (it's simple for me to do now). |
Sure thing. Thank you. |
Validating and potentially fixing github#976
Initial commit adds a local test that attempts to reproduce github#976. We expect that test to fail.
cc @derekPNM