直接改从库字段类型为longtext可恢复同步，需先通过show slave status\g确认last_sql_errno=1677、last_sql_error含“cannot be converted from type 'longblob' to type 'text'”及slave_sql_running=no，再用show create table验证主库为longblob、从库为text类即定位准确。
直接改从库字段类型为 longtext 就能恢复同步，但必须确认主从表结构差异是否仅限于此字段，否则可能掩盖更严重的不一致。
怎么快速定位是 longblob → text 类型不兼容？
从库执行 SHOW SLAVE STATUS\G，重点看这三处：
-
Last_SQL_Errno是1677（MySQL 类型转换错误码） -
Last_SQL_Error明确含cannot be converted from type 'longblob' to type 'text' -
Slave_SQL_Running为No，且Exec_Master_Log_Pos停在出错事务的起始位置
再查表结构：SHOW CREATE TABLE lxpm.sys_oper_log\G（把报错中的库名和表名代入），对比主从两端第 8 列（或对应字段名，如 returns）的定义。只要主库是 longblob、从库是 text 或 mediumtext，就坐实了问题根源。
为什么不能只用 ALTER TABLE ... MODIFY COLUMN 简单改类型？
因为 text 和 longblob 虽然都存大对象，但底层处理逻辑不同：前者按字符集解析，后者按字节流处理。MySQL 在 ROW 格式 binlog 回放时会严格校验列元数据，类型不匹配直接中止 SQL 线程。
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 直接
MODIFY COLUMN returns TEXT可能失败（尤其当字段有默认值或非空约束时） - 正确做法是用
longtext对齐：它和longblob具有相同的最大长度（4GB），且 MySQL 允许在 ROW 复制下无损转换 - 命令示例：
ALTER TABLE lxpm.sys_oper_log MODIFY COLUMN returns LONGTEXT;
改完字段后启动同步前，必须检查什么？
改完别急着 START SLAVE。先确认两个关键点：
- 主库
binlog_format必须是ROW（SELECT @@binlog_format;），如果是MIXED或STATEMENT，类型不一致可能引发更隐蔽的回放失败 - 从库
slave_type_conversions参数若被设为非空（如ALL_NON_LOSSY），反而会干扰类型对齐逻辑，建议保持默认空值 - 执行
STOP SLAVE; SET GLOBAL sql_slave_skip_counter = 1; START SLAVE;跳过当前卡住的事务（仅限已确认该事务不涉及关键业务逻辑）
最容易被忽略的后续风险
这类问题几乎总是人为操作导致：主库改了表结构但没同步到从库。所以修复后必须做两件事：
- 立刻检查所有从库是否都执行了相同
ALTER，避免部分从库仍卡住 - 把这次 DDL 加入上线流程 checklist：任何修改
BLOB/TEXT类型的操作，必须先在从库执行对应变更，再在主库执行
否则下次主库再执行一次 ALTER TABLE ... MODIFY COLUMN returns LONGBLOB（比如加个注释），从库又会因“类型变回去”而再次报错——错误信息看起来一样，但原因已变成反向不兼容。
