fix: issue 909 #915
fix: issue 909 #915
Conversation
|
Hi @cenkore! Thanks for the contribution! It seems like the build is failing because it's it's not properly formatted with gofmt. Could you please run the following command on the branch? |
|
@rashiq , thanks for your suggestion, it looks good! |
|
Hi, @cenkore! We checked your PR on test db and it works like a charm! Thank you! |
|
@cenkore Thanks! We've deployed it to our testing cluster, will monitor it the coming few days and if everything is fine we'll merge it 👍 |
Thank you! |
|
@rashiq is any updates? thx |
go/sql/types.go
Outdated
|
|
||
| if this.Type == BinaryColumnType { | ||
| size := len([]byte(arg.(string))) | ||
| if uint(size) < this.BinaryOctetLength { | ||
| buf := bytes.NewBuffer([]byte(arg.(string))) | ||
| for i := uint(0); i < (this.BinaryOctetLength - uint(size)); i++ { | ||
| buf.Write([]byte{0}) | ||
| } | ||
| arg = buf.String() | ||
| } | ||
| } | ||
|
|
There was a problem hiding this comment.
Could you please explain what the logic above does? Thank you!
There was a problem hiding this comment.
This is all about this issue #909
Also, U can read this https://dev.mysql.com/doc/refman/5.7/en/binary-varbinary.html
You should consider the preceding padding and stripping
characteristics carefully if you plan to use the BINARY
data type for storing binary data and you require that
the value retrieved be exactly the same as the value stored.
The following example illustrates how 0x00-padding
of BINARY values affects column value comparisons
Please, read @cenkore's first message:
The reason is that the last byte of 0x00 was truncated
when mysql wrote Binlog, so the data obtained when
gh-ost parsed binlog through go-mysql was already truncated
So, this part of code appends missing zeroes.
We use this fork on production about a month, and all is OK.
There was a problem hiding this comment.
Thank you. Is there a limit on how many zeros you need to pad with, or can this number be very high?
There was a problem hiding this comment.
@shlomi-noach Filling a high number zero bytes may affect processing efficiency. after thinking about it, we can fix it more lighter as below, other scenarios will not cause data consistency problems. 40bc5ae
- only handle the binary column in the unique key
- only handle update/delete dml event
|
Sorry it took so long! merged! 🎉 |
Add a PR for #909
The reason is that the last byte of 0x00 was truncated when mysql wrote Binlog, so the data obtained when gh-ost parsed binlog through go-mysql was already truncated
you can read binlog with hexdump as follows, or debug at here , you will get the actual length is 15