last_errno: 1677 是字符集不一致的明确信号，需同步统一服务端配置、表定义及复制连接层字符集；确认方法为检查show slave status中的last_sql_error提示，并比对主从表结构的default charset与显式character set/collate；必须修改my.cnf中[mysqld]的character-set-server和collation-server，用convert to而非modify column迁移数据，且需确保复制线程连接层字符集（@@character_set_client等）也设为utf8mb4。
Last_Errno: 1677 基本就是字符集不一致的铁证，必须从服务端配置、表定义、复制连接三处同时对齐，只改一处等于白干。
怎么确认是字符集导致的 1677 报错
先在从库执行 SHOW SLAVE STATUS\G，看 Last_SQL_Error 是否含类似 cannot be converted from type 'varchar(1536)' to type 'varchar(2048) utf8mb4' 的提示。接着分别在主从库执行：
SHOW CREATE TABLE your_db.your_table\G
重点比对两处输出里的 DEFAULT CHARSET 和字段定义中显式写的 CHARACTER SET 与 COLLATE——别信 character_set_database，它只是默认值，真正起作用的是表和列自己声明的字符集。
统一主从 character_set_server 和 collation_server
这是所有新建库/表的默认源头，不一致会导致后续建表自动继承不同字符集。在主从两端的 my.cnf 的 [mysqld] 段落里都加上：
character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci
然后重启 MySQL。注意：SET GLOBAL character_set_server = 'utf8mb4' 只对新连接生效，且不持久，不能替代配置文件修改。
用 CONVERT TO 修复已有表，不是 MODIFY COLUMN
ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci 是唯一安全的全量迁移方式，它会同时转换列数据、列定义、索引和默认校对规则。
- 别用
MODIFY COLUMN xxx VARCHAR(255) CHARACTER SET utf8mb4：只改单列定义，不改已有数据编码，也不影响其他列和索引 - 漏掉
COLLATE很危险：比如只写CONVERT TO CHARACTER SET utf8mb4，MySQL 会用默认utf8mb4_general_ci，但如果主库原表是utf8mb4_unicode_ci，从库重放时可能因比较逻辑差异报错 - 含外键或全文索引的表要提前验证：
CONVERT TO可能失败，需先删后加，生产环境务必提前测试
检查并修正复制线程自身的连接层字符集
复制线程本质是一个特殊客户端连接，它的行为受从库的 @@character_set_client、@@collation_connection 控制。执行：
SELECT @@character_set_client, @@collation_connection;
如果返回不是 utf8mb4 和 utf8mb4_unicode_ci，说明复制线程正在用错误的编码解析 binlog 字节流——哪怕表结构完全一致，照样报 1677。修复方法是在从库 my.cnf 的 [client] 或 [mysql] 段落里加：
default-character-set = utf8mb4
并确保从库启动时该配置被加载（部分版本需同时配 [mysqld] 和 [client] 才生效）。
最易被忽略的一点：即使你把所有配置都改对了，只要有一张表在主库建的时候没写 CHARACTER SET，而主从 character_set_database 不同，这张表就天然不一致——所以今后所有 DDL 都得显式带 CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci。
