source-mysql: Support collation utf8_general_ci
#2056
Assignees
Labels
change:unplanned
Unplanned change, useful for things like doc updates
Comments
willdonnelly
added
the
change:unplanned
|
According to a quick spot check, collations named |
willdonnelly
added a commit
that referenced
this issue
Oct 15, 2024
The collation families `utf8_whatever` and `ascii_whatever` are explicitly added to the charsets table so we stop logging errors reading `unknown charset for collation, assuming UTF-8` and just do that without complaining because UTF-8 is in fact correct. The `replication connected without TLS` log message is downgraded from WARN to INFO to match the main (non-replication) connection logging. Between these fixes, that's all the main sources of errors and warnings in our production MySQL tasks, so hopefully that will be much less noisy to keep an eye on in the future. This fixes #2056
willdonnelly
added a commit
that referenced
this issue
Oct 15, 2024
The collation families `utf8_whatever` and `ascii_whatever` are explicitly added to the charsets table so we stop logging errors reading `unknown charset for collation, assuming UTF-8` and just do that without complaining because UTF-8 is in fact correct. (This requires another minor tweak, because the way we match up a collation name to a character set is by simple prefix matching, and `utf8` is a prefix of the `utf8mb3` and `utf8mb4` collations. But a collation name is actually `<charset>_<comparisonRule>` with an underscore, so to fix that we just have to do a prefix match including that trailing underscore. This should still work the same for all collation names that actually exist.) The `replication connected without TLS` log message is downgraded from WARN to INFO to match the main (non-replication) connection logging. Between these fixes, that's all the main sources of errors and warnings in our production MySQL tasks, so hopefully that will be much less noisy to keep an eye on in the future. This fixes #2056
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There's some historical reason stuff going on with that collation name, but for our purposes we don't care and should treat it as UTF-8 text just like we do
utf8mb3_foobarandutf8mb4_foobarcollations.In fact that's already what we do, but only because we have a nice default behavior of "if we don't recognize it, assume it's UTF-8 compatible". So really adding this explicitly will just eliminate a benign error log, but that's still worth doing at some point.
The text was updated successfully, but these errors were encountered: