Bump go-mysql dependency

[tiwilliam]

Current go-mysql vendor is from 2018 and don't include support for UNIX sockets. This was fixed 15 commits after our frozen commit. This pull will bring in the latest go-mysql.

We also set source and target port to 0 when using UNIX sockets since this is how go-mysql distinguish a UNIX config:
https://github.com/siddontang/go-mysql/blob/master/replication/binlogsyncer.go#L829

[shuhaowu]

We need to audit the changes from the version we pin until this new version as this is a high risk change.

[tiwilliam]

Yeah, kind of understood that, 89 commits, 4,656 additions and 18,017 deletions.

go-mysql-org/go-mysql@58848a7...803944a

[shuhaowu]

I'll look through that list and pull out the highlights in a comment below.

[shuhaowu]

go-mysql changes go-mysql-org/go-mysql@58848a7...803944a

• go-mysql-org/go-mysql@8939dbe (PR: fix error checking and rawData in parseSingleEvent function go-mysql-org/go-mysql#305): A bug fix with respect to TableMapEvent?
• go-mysql-org/go-mysql@0f2e7f6 (PR: row_event.go: fix the set bytes value in revert order go-mysql-org/go-mysql#319): some bugfixes when handling binlogs with SET, ENUM, BIT types. It looks like previously the decoded binlog was incorrect?
  • go-mysql-org/go-mysql@83f8eae (PR: row_event_test.go: add test for multi bytes Enum encode go-mysql-org/go-mysql#320): More ENUM test cases.
• go-mysql-org/go-mysql@76c059e (PR: support Decimal type go-mysql-org/go-mysql#332): schema.TableColumn now supports DECIMAL.
  • I recall that we had to support DECIMAL at some point, this commit adds DECIMAL support to canal (not something we use). We should see if we can use the new DECIMAL option on TableColumn.
• go-mysql-org/go-mysql@8b47113 (PR: Add support for MySQL 8.0 and support for TLS/SSL for both Server and Client go-mysql-org/go-mysql#312): Added support to MySQL 8, but this mostly seems like changes with the go-mysql/client code. Replication code looks minimally changed.
  • A bit while later we see that the table map event gets the table schema? go-mysql-org/go-mysql@514d075 (PR: Add more MySQL-8.0 meta data to GTIDEvent and TableMapEvent go-mysql-org/go-mysql#468).
    • This could be extremely helpful once we move to MySQL 8, but the code is hard to review quickly now as it's 800+ lines as well as a lot of MySQL internals.
  • More MySQL 8 binlog changes:
    • PR: Add more MySQL-8.0 meta data to GTIDEvent and TableMapEvent go-mysql-org/go-mysql#468 (multiple commits)
• go-mysql-org/go-mysql@7fc3b28 (PR: add compatibility to json decode for generated column go-mysql-org/go-mysql#372): More JSON fixes that works around MySQL bugs that I don't quite understand.
• go-mysql-org/go-mysql@8b9c05e (PR: fix(canal): fix mysql unsigned medium int go-mysql-org/go-mysql#399): Handling unsigned MEDIUMINT seemed to require some nudges in canal, which implies that it may require some code changes here in Ghostferry.
  • MEDIUMINT is 3 byte which can cause problems when casting.
• go-mysql-org/go-mysql@046188b (PR: do not sync persistent store when get a fake position go-mysql-org/go-mysql#397): They're ignoring fake rotate event in canal. We should cross reference our fix for this with theirs.
  • Original bug report for this is in Chinese, which appears to describe a situtation where Canal can be restarted from a binlog position after a table map event (in their case it seems to stem from a delete table, which generates a large amount of binlog entries). Some explanation on how to fix is in English.
  • More related commits: go-mysql-org/go-mysql@cb33eb8 (PR: fix(canal): Preserve binlog filename received in the fake rotate event go-mysql-org/go-mysql#428)
    • This appears to be address how binlog file names are handled in Canal, which we've also independently worked on.
  • We should evaluate if our fix for resumable binlog position matches theirs, cc: @fjordan
• go-mysql-org/go-mysql@803944a (PR: go-mysql-org/go-mysql@803944a) Binary column fix by our friend @kolbitsch-lastline
  • I don't recall the status of how we handled the BINARY column patch. Maybe a good idea to revisit it now.

Nothing looks too crazy. MySQL 8 changes is great, but pretty new. I haven't had a chance to review all the code in PR 468 and if it would have any impact on us as we don't use MySQL 8. Some bug fixes in Canal caught my eye as we independently did this. Also saw a lot of work on GTID stuff that we don't use.

[shuhaowu]

Also interesting to note that once we merge this theoretically we can support MySQL 8... but that requires extensive validation...

[tiwilliam]

Changes look good to me. I've been testing this branch using copydb on a dry-run attempt to move 1 TB of data via UNIX sockets. Everything went smooth.

[hkdsun]

SGTM if Shuhao is happy with the upstream changes