error执行row event是因从库缺失表、字段不匹配或记录不存在，根本原因是schema或数据状态未与主库对齐；需通过show slave status定位last_errno（如1146/1032/1666）和last_error，再检查库表存在性、binlog_format一致性，并针对性导出导入缺失库或修正配置。
这是从库执行主库发来的 row-based binlog 事件时，找不到对应表或数据导致的硬性失败，不能靠跳过事务解决，必须对齐 schema 和数据状态。
为什么出现 Error executing row event？
根本原因是：从库 SQL 线程尝试重放主库的 row event（比如 UPDATE_ROWS、DELETE_ROWS），但目标表不存在、字段不匹配、或某行记录在从库上根本不存在。
常见触发场景包括：
- 主库删了表，但 binlog 里没记录
DROP TABLE（尤其用binlog-ignore-db过滤时）；从库没该表，却收到对该表的 row event - 主库有
zabbix库，但从库没导入，直接启 slave 就会报Table 'zabbix.history_uint' doesn't exist - 主库执行了 DDL（如
ALTER TABLE），但从库 schema 没同步，row event 中列数/类型与实际表结构不符 - 主从 binlog_format 不一致：主库是
ROW，从库设成STATEMENT，导致从库无法解析 row event
如何确认具体出错点？
先查 SHOW SLAVE STATUS\G，重点关注三处：
-
Slave_SQL_Running: No—— SQL 线程已停 -
Last_Errno（如1146表不存在、1032找不到记录、1666binlog_format 冲突） -
Last_Error字段里的完整报错，例如Error executing row event: 'Table 'zabbix.history_uint' doesn't exist'
如果报错指向某个库或表，立刻检查从库是否存在该库：SHOW DATABASES LIKE 'zabbix';，再进库查表：USE zabbix; SHOW TABLES LIKE 'history_uint';
怎么安全重新同步？
跳过事务（SET GLOBAL sql_slave_skip_counter = 1）只适用于偶发性单条数据不一致，对 schema 缺失或格式错配无效，强行跳过会导致后续持续报错。
正确做法分两类：
-
缺失库/表：从主库导出对应库（
mysqldump -u root -p --master-data=2 zabbix > zabbix.sql），scp 到从库，CREATE DATABASE zabbix;后导入，再START SLAVE; -
binlog_format 不匹配：在从库执行
SET GLOBAL binlog_format = 'ROW';，并确认已写入/etc/my.cnf的[mysqld]段落（否则重启失效） -
relay log 损坏或 position 错位：用
SHOW SLAVE STATUS查Relay_Master_Log_File和Exec_Master_Log_Pos，然后STOP SLAVE; CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000025', MASTER_LOG_POS=1010663436; START SLAVE;
注意：--master-data=2 参数必须加，它会在 dump 文件里写入 CHANGE MASTER 所需的 binlog 位置，避免手动算 offset 出错。
最容易被忽略的细节
很多故障表面看是“表不存在”，实际根子在配置层：比如主库开了 binlog-do-db=traffic，但误操作在 zabbix 库建表，这部分 binlog 不会被记录，从库自然没机会同步该库——此时不是重同步问题，而是主库 binlog 过滤策略本身就不支持跨库复制。
