主从复制SQL线程中断——字符集砸出的坑

一、问题现场：SQL 线程中断，但表结构一致

告警响起：异步复制的 slave 端 SQL 线程中断了。查询表 replication_applier_status_by_worker检查报错信息：

GreatSQL > SELECT * FROM performance_schema.replication_applier_status_by_worker\G;
*************************** 1. row ***************************
                                      SERVICE_STATE: OFF
                                  LAST_ERROR_NUMBER: 13146
                                 LAST_ERROR_MESSAGE: Worker 1 failed executing transaction
 'f08e63fb-3b91-11f0-af59-5254d9b382e7:66192867' at master log binlog.000423, end_log_pos 115725003;
 Column 1 of table 'gsqldb_xxx.dynamic_yyy_log' cannot be converted
 from type 'varchar(128(bytes))' to type 'varchar(96(bytes) utf8mb3)'
 ...

报错很直白：事务66192867在回放时，列类型"转换失败"。

核对主从表结构：

GreatSQL > SHOW CREATE TABLE gsqldb_xxx.dynamic_yyy_log\G;
CREATE TABLE `dynamic_yyy_log` (
  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '自增ID',
  `business_id` varchar(32) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT NULL COMMENT '业务主键',
  `serial` varchar(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT NULL COMMENT '设备唯一编号',
  `push_time` datetime DEFAULT NULL COMMENT '上传时间',
  `remark` varchar(255) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci DEFAULT NULL COMMENT '备注',
  `sort` int DEFAULT '0' COMMENT '排序',
  `create_by` varchar(64) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci DEFAULT NULL COMMENT '创建人',
  `edit_by` varchar(64) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci DEFAULT NULL COMMENT '最后编辑人',
  `time_created` datetime NOT NULL COMMENT '记录创建时间',
  `time_modified` datetime NOT NULL COMMENT '记录修改时间',
  `status` varchar(32) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci DEFAULT NULL COMMENT '状态',
  `operation` varchar(32) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci DEFAULT NULL COMMENT '操作',
  `version` int DEFAULT '0' COMMENT '乐观锁',
  `deleted` int DEFAULT '0' COMMENT '逻辑删除',
  PRIMARY KEY (`id`) USING BTREE,
  KEY `business_id` (`business_id`) USING BTREE,
  KEY `comp_business_id` (`serial`) USING BTREE,
  KEY `sort` (`sort`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1083580 DEFAULT CHARSET=utf8mb3 ROW_FORMAT=DYNAMIC;

让人困惑的是：主从两端的表结构完全一致，business_id 都是 varchar(32) utf8mb3。那么，SQL 线程到底在抗议什么？

二、细看报错信息：LAST_ERROR_MESSAGE 透露了什么

把报错拆开看，能看出两层关键信息：

  1. 问题出在哪一列：报错说 Column 1。注意这里的列号从 0 开始编号，所以 Column 1 对应的是表里的第二列——business_id。
  2. 直接原因是什么：cannot be converted from type 'varchar(128(bytes))' to type 'varchar(96(bytes) utf8mb3)'。也就是 slave 在回放时，发现 binlog 里记录的列长度（128 字节）和本地表定义（96 字节）对不上，拒绝转换。

到这里，矛盾点已经浮现：本地表定义里 business_id 是 varchar(32) utf8mb3，怎么会转换 varchar(128(bytes))呢？

三、大胆假设：做了什么操作

  • slave 端是 varchar(32) utf8mb3。utf8mb3 每个字符最多占 3 字节，32 个字符对应 96 字节——正好对应报错里的 varchar(96(bytes) utf8mb3)。
  • 但 master 端在 binlog （slave 的 relaylog）中记录的是 varchar(128(bytes))。128 不能被 3 整除，却能被 4 整除，商是32，正好和varchar(32)对应。如果字符集是utf8mb4，一个字符最多占 4 字节，varchar(32) utf8mb4就是varchar(128(bytes))。

由此可以合理推测 master 上发生过的操作：

master 端在 sql_log_bin=off 的情况下，把 business_id 改成了 utf8mb4 ，执行了insert操作，binlog中记录了varchar(128(bytes))；随后(或许是发现了 slave 的SQL线程中断后)，又在 sql_log_bin=off 下把 business_id 改回了 utf8mb3，使表的结构在主从两端重新"看起来"一致了。

四、实验验证

大胆的假设有了，现在需要小心求证。

4.1 实验设计

  1. 搭建异步复制环境，在 master 建表 dynamic_yyy_log 并插入数据，确认复制正常。
  2. master 在 sql_log_bin=off 下把 business_id 改成 utf8mb4，再插入一条数据，观察 slave 是否中断及报错。
  3. 观察 slave 的 SHOW SLAVE STATUS 与 replication_applier_status_by_worker。

4.2 实验步骤

步骤 1：建表并验证复制

INSERT INTO dynamic_yyy_log(id,business_id,serial,time_created,time_modified)
VALUES(1,'11111','11111',NOW(),NOW());

步骤 2：关键操作——关 binlog 改字符集，插数据****，关binlog改回字符集

-- 将列business_id有utf8mb3改为utf8mb4
SET sql_log_bin=off;
ALTER TABLE dynamic_yyy_log MODIFY COLUMN `business_id`
  varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '业务主键';
SET sql_log_bin=on;

-- 在utfmb4下执行insert
INSERT INTO dynamic_yyy_log(id,business_id,serial,time_created,time_modified)
VALUES(2,'22222','22222',NOW(),NOW());

-- 将列business_id有utf8mb4改为utf8mb3
SET sql_log_bin=off;
ALTER TABLE dynamic_yyy_log MODIFY COLUMN `business_id`
  varchar(32) CHARACTER SET utf8mb3 COLLATE utf8mb3_general_ci NOT NULL COMMENT '业务主键';
SET sql_log_bin=on;

步骤 3：观察 slave

GreatSQL > SHOW SLAVE STATUS\G
...
             Slave_IO_Running: Yes
            Slave_SQL_Running: No
                   Last_Errno: 13146
                   Last_Error: Coordinator stopped because there were error(s) in the worker(s).
 The most recent failure being: Worker 1 failed executing transaction
 '0ecdbd10-21e1-11f1-ae16-00163e892deb:415' at master log binlog.000001, end_log_pos 190926334.
 ...

再看 worker 明细：

GreatSQL > SELECT * FROM performance_schema.replication_applier_status_by_worker LIMIT 1\G;
                                      SERVICE_STATE: OFF
                                  LAST_ERROR_NUMBER: 13146
                                 LAST_ERROR_MESSAGE: Worker 1 failed executing transaction
 '0ecdbd10-21e1-11f1-ae16-00163e892deb:415' at master log binlog.000001, end_log_pos 190926334;
 Column 1 of table 'testdb.dynamic_yyy_log' cannot be converted
 from type 'varchar(128(bytes))' to type 'varchar(96(bytes) utf8mb3)'
 ...

报错与现场问题完全一致，此时查询表的结构信息，列business_id都是utf8mb3。 问题发生的假设得到验证。

五、延伸问题

5.1 binlog 里记录了列的类型、长度、字符集吗？

mysqlbinlog -v解析事务 0ecdbd10-21e1-11f1-ae16-00163e892deb:415 的 binlog，关键片段如下：

### INSERT INTO `testdb`.`dynamic_yyy_log`
### SET
###   @1=2                          /* LONGINT meta=0   */
###   @2='22222'                    /* VARSTRING(128) meta=128 nullable=0 */
###   @3='22222'                    /* VARSTRING(765) meta=765 nullable=0 */
###   @9='2026-03-18 09:43:37'      /* DATETIME(0)     */
...

结论很明确：

  • binlog 记录了列的类型与字节长度。@2 列（即 business_id）被记为 VARSTRING(128)，128 正是该列在 utf8mb4 下的字节数。
  • binlog 没有记录列的字符集。binlog中只记录了列"占多少字节"，并未记录列的字符集。

5.2 出了事，怎么救？

既然根因是 slave 本地列"长度"和 binlog 不一致，解法就是让 slave 对齐 master 写 binlog 时的状态——把 business_id 也改成 utf8mb4：

SET sql_log_bin=off;
ALTER TABLE dynamic_yyy_log MODIFY COLUMN `business_id`
  varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci NOT NULL COMMENT '业务主键';
SET sql_log_bin=on;

改完后 START SLAVE这个事务可以继续回放。但主从字符集不一致（主utf8mb3，从utf8mb4），那么，什么时候还需要再改一次字符集？

5.3 有没有"容忍"类型或长度变化的开关？

GreatSQL 提供了系统变量来控制主从之间的类型转换容忍度replica_type_conversions。

  • 默认值（空字符串）：禁止任何属性提升或降级，主从对应列的长度和类型必须完全一致。本次问题中该变量正是空值，所以一遇到 128 vs 96 就直接报错。
  • ALL_LOSSY 允许会造成信息丢失的转换。
  • ALL_NON_LOSSY 允许不需要截断、无需特殊处理原始值的转换；即目标类型的取值范围能覆盖源类型。
  • ALL_LOSSY,ALL_NON_LOSSY 开启后，所有支持的类型转换都允许，无论是否有损。
  • ALL_SIGNED 属性提升后的整数视为有符号类型（默认行为）。
  • ALL_UNSIGNED 属性提升后的整数视为无符号类型。
  • ALL_SIGNED,ALL_UNSIGNED 优先将提升后的整数按有符号处理；无法容纳时，则按无符号处理。两个配置的书写顺序无影响。

结语

这次中断的表象是"表结构不一致"，真相却是"结构一致、历史 binlog 不一致"。字符集这种看似无害的字段属性，一旦在 sql_log_bin=off 下被悄悄改动，DML操作就会在 binlog 里留下历史痕迹，等 slave 回放时就可能跳出来叫停SQL线程。

对于DBA的启示：

  • 但凡涉及到“主从复制类型转换失败”情况的，基本上都可以第一时间往字符集不一致方向去排查。
  • 日常巡检时，对比主从两端数据列的长度、字符集、排序规则是否一致。
  • 不要在 sql_log_bin=off 下改列定义，列的字符集/长度变更要走正常 DDL 流程，让变更进入 binlog，保证主从同步演进。

老叶有话说

GreatSQL 社区现已上线“AI助手”功能，我试着把这个问题丢给它，互动结果如下。

问：

GreatSQL主从复制结构中，从服务器上报告错误：Column 1 of table 'zhgd_screen.dynamic_device_status_log' cannot be converted
from type 'varchar(128(bytes))' to type 'varchar(96(bytes) utf8mb3)' 这种情况下一般是什么原因导致，如何分析排查

AI助手回答：

先说明一下：我检索了官方手册，未查到针对这条报错文案的专项条目，下面基于 MySQL/GreatSQL 行复制（ROW format）的通用机制给您分析，具体细节请以官方手册为准。

一、这个报错的本质

这是典型的 RBR（行复制）列类型不匹配错误（对应 MySQL 错误码 1677 ER_SLAVE_CONVERSION_FAILED）：

  • 主库以 ROW 格式记录 binlog，里面带有主库表的列元数据；
  • 从库回放 TABLE_MAP / 行事件时，会把主库列定义和本地表的列定义逐列比对，只有"可安全转换"才放行；
  • 报错说明第 1 列两边定义不一致，无法转换。

报错里的字节数很关键：

  • 主库侧：varchar(128(bytes)) —— 列最大容量 128 字节；
  • 从库侧：varchar(96(bytes) utf8mb3) —— 96 字节且字符集是 utf8mb3。

一个很典型的对应关系是：主库 VARCHAR(32) utf8mb4（32×4=128 bytes），从库 VARCHAR(32) utf8mb3（32×3=96 bytes）——字符数相同，但两边建表时的默认字符集不同，导致表结构"漂移"了。GreatSQL 8.0 起默认字符集为 utf8mb4，而 utf8 是 utf8mb3，若从库是老版本迁移过来或建库时未显式指定字符集，就很容易出现这种差异 GreatSQL 官方手册 - 字符集 & 校验集↗。

二、常见成因（按概率排序）

  1. 两边默认字符集不一致时各自建表：主库 character_set_server=utf8mb4，从库还是旧的 utf8mb3/latin1，表不是通过复制建的，而是各自初始化或分别导入的。
  2. 单边 DDL 导致结构漂移：
    • DBA 在从库上直接 ALTER 做验证，主库没执行；
    • 主库 ALTER 后，从库执行失败被跳过（检查是否配置了 replica_skip_errors / slave_skip_errors 跳过了 1xxx DDL 错误）；
    • 复制过滤规则（Replicate_Do_DB / Replicate_Ignore_DB 等）把这条 DDL 过滤掉了。
  3. 从库表被外部任务覆盖：备份恢复、数据导入脚本、初始化任务在从库上重建了这张表，用的是不同 --default-character-set 的 dump。
  4. 历史架构调整：从库曾是别的主库的从库，或做过切换后表结构没对齐。

三、排查步骤

1. 看复制状态，拿到出错时间线

SHOW REPLICA STATUS\G
-- 关注 Replica_SQL_Running、Last_SQL_Error、Last_SQL_Error_Timestamp
-- 旧语法 SHOW SLAVE STATUS 也可用，GreatSQL 新旧两套语法并行兼容

GreatSQL 官方手册 - 恢复部分主从复制兼容接口↗

2. 两边对比表结构（核心步骤）

分别在主库和从库执行：

SHOW CREATE TABLE zhgd_screen.dynamic_device_status_log\G

SELECT COLUMN_NAME, ORDINAL_POSITION, COLUMN_TYPE,
       CHARACTER_SET_NAME, COLLATION_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA='zhgd_screen'
  AND TABLE_NAME='dynamic_device_status_log';

把两边结果逐列 diff，重点看第 1 列的 COLUMN_TYPE 和 CHARACTER_SET_NAME。

3. 检查环境差异

SHOW VARIABLES LIKE 'character_set_server';
SHOW VARIABLES LIKE 'collation_server';
SHOW VARIABLES LIKE 'binlog_format';          -- 主库应为 ROW
SHOW REPLICA STATUS;                          -- 看 Replicate_* 过滤规则
SHOW VARIABLES LIKE '%skip_errors%';          -- 是否配置了跳错

4. 追溯 DDL 历史：用 mysqlbinlog 在主库 binlog 中搜该表名，看这张表的 ALTER/CREATE 记录是否都到达了从库；结合 Last_SQL_Error_Timestamp 缩小时间窗。

5. 数据层校验：结构对齐后，建议用 pt-table-checksum 校验主从数据是否还有其他隐性差异。

四、修复建议

  • 以主库为准修正从库结构（执行前先 STOP REPLICA）：
STOP REPLICA;
ALTER TABLE zhgd_screen.dynamic_device_status_log
  MODIFY 第1列列名 <与主库完全一致的定义>;
START REPLICA;
  • ⚠️ 如果从库该列比主库窄且已有存量数据，MODIFY 时可能因数据超出长度/字符集表示不了而失败；这种情况下更稳妥的做法是在从库重建表（CREATE TABLE ... LIKE 主库表结构）再回填数据。
  • ❌ 不建议用 replica_skip_errors=1677 直接跳过——事件是跳过去了，但主从数据从此不一致，后患更大。只有在明确接受数据差异、紧急恢复复制时才考虑跳过单个事件。
  • 预防：两边统一 character_set_server/collation_server；建库建表显式写 CHARACTER SET utf8mb4；DDL 统一走变更流程、严禁在从库单边执行；定期用 pt-table-checksum 巡检。

如果您把主库和从库两边 SHOW CREATE TABLE 的结果贴出来，我可以帮您精确定位是哪一列、哪种差异导致的。也可以到技术论坛发帖讨论：技术论坛

posted @ 2026-10-13 10:04  GreatSQL  阅读(6)  评论(0)    收藏  举报