UCS2 to UTF8MB4 Encoding error

未关闭
#1,438 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 10 天内回复

还没有人认领这个 Issue。

评估

难度
4/5
预计耗时
3-5 天
新手友好度
25/100
Issue 类型
缺陷
描述清晰度
需要澄清
活跃度
停滞
技术栈
mysql
领域
database

调研方向

复现一次涉及 UCS2 和 UTF8MB4 的在线迁移,然后检查从 binlog 读取的行如何插入或更新到 gho 表中。比较转换前后的存储字节和字符值。完成标准是等价字符仍能被正确表示,且不需要手动执行 UPDATE 语句。

由索引模型根据 Issue 内容生成。

描述

Not sure if this is expected for fixed-length to variable length charset conversions but for rows read from the binlog into the gho table during the migration, the utility does not do an equivalent character conversion, it just uses the bytes given with the new charset. I could see why this behavior might make sense (charsets may not necessarily have truly equivalent representations of the same displayed character?) and is a skill issue in my part but in case this is not expected behavior, the example I saw during my migration was as follows:

"M" in UCS2: 0x004D
"M" in UTF8MB4: 0x4D

I am in the process of fixing it in my DB by running UPDATE statements in the format:

{column} = IF(CAST({column} AS BINARY) LIKE CONCAT(0x00, '%'), CONVERT(CONVERT(CAST({column} AS BINARY) USING UCS2), USING UTF8MB4), {column})

With some appropriate filters to not have to attempt to update every row of the new table of course. Is this something that gh-ost should handle itself? I think the format above allows specifically UCS2 to UTF8, if it were ran against the gho table rows upon insertion/update from the binlog but it's probably not portable outside this specific case.

Either way, this is a fantastic tool and I really appreciate that you all made this. Thanks

主要语言
Go
星标
13.6k
派生
1.4k
平均合并
9 天 19 小时
30 天内合并 PR
1

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

github/gh-ost 的其他 Issue

查看 github/gh-ost 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。