pt-o-s-c still processes the table correctly (utf8mb4 symbols stored in additional varchar field are valid after pt-o-s-c run). 4-byte changes also processed correctly by pt-o-s-c triggers.
Possible fix: use binary or hex literals instead of '?' substitution.
Environment
None
AFFECTED CS IDs
235580,223509
Attachments
1
Smart Checklist
Activity
Show:
Carlos Salguero December 16, 2020 at 6:21 PM
As far as I can see, it is only a warning.
, could you check downloading this version please?
Thanks.
Carlos Salguero November 22, 2020 at 9:59 PM
Estimated in 1 story point. Made a draft PR.
Nurlan Moldomurov November 9, 2020 at 12:55 PM
will prepare this task for the next grooming
Thomas bruckmann September 15, 2020 at 12:37 PM
This Bug also still exists in 3.2.1 in Combination with Percona MySQL 8 also the workaround described above does not work anymore. This means, we are not able to alter tables currently in our setup, since the Tables are blocked for hours. So to increase the prio for this Ticket seems absolutly neccessary, because this error means that pt-o-s-c is not usable with Version 8.
Mark Rose January 28, 2019 at 7:10 PM
This bug is still present in 3.0.13. Just ran into it.
Hi,
pt-online-schema-change could emit utf8 errors for binary PK:
Load
to test database
The output:
Workaround specify latin1 charset for pt-o-s-c:
pt-online-schema-change --execute --charset=latin1 --chunk-size 2 --alter 'engine=innodb' D=test,t=brokenutf8alter
pt-o-s-c still processes the table correctly (utf8mb4 symbols stored in additional varchar field are valid after pt-o-s-c run). 4-byte changes also processed correctly by pt-o-s-c triggers.
Possible fix: use binary or hex literals instead of '?' substitution.