MySQL主库binlog写入失败导致从库复制中断，错误1590（LOST_EVENTS）表明主库磁盘满、权限不足或文件系统异常，须先修复主库binlog再重设从库同步起点。
“The incident event has occurred on master” 是 MySQL 主从复制中一个明确的信号：主库 binlog 写入失败，从库无法继续回放，必须人工介入。 它不是网络抖动或临时冲突，而是主库自身已发生严重日志写入异常，直接导致复制链路断裂。不能跳过、不能硬启，得先稳住主库状态再处理从库。
为什么会出现 LOST_EVENTS 错误（Error_code 1590）
这个错误对应 LOST_EVENTS 类型的 binlog incident 事件，本质是主库在写 binlog 时出错了——比如磁盘满、权限不足、文件系统只读、binlog 文件损坏或被外部进程强制截断。MySQL 检测到写入不完整，会主动插入一条 INCIDENT_EVENT 到 binlog 中标记“后续事件丢失”，从库读到这条事件后立即中止 SQL 线程，并报错 Last_SQL_Error: The incident LOST_EVENTS occured on the master. Message: error writing to the binary log。
关键点：
- 错误源头一定在主库，且已发生过一次 binlog 写失败，不是从库配置问题
- 从库报错位置（
Exec_Master_Log_Pos）指向的是 incident 事件本身，不是它后面的语句 - 该错误下
Slave_SQL_Running必为No，Seconds_Behind_Master为NULL
先查主库：确认 binlog 是否还能正常写入
登录主库，执行以下检查：
- 运行
df -h查看datadir和log_bin所在分区是否磁盘已满或只读 - 检查 MySQL 错误日志（通常是
/var/log/mysql/error.log或mysqld.err），搜索关键词error writing to the binary log、Failed to write、no space left - 执行
SHOW BINARY LOGS;，确认当前 binlog 文件是否可列出；若报错或列表为空，说明 binlog 系统已瘫痪 - 尝试手动触发一次写操作：
FLUSH LOGS;—— 如果失败，坐实 binlog 不可用
如果主库 binlog 仍不可写，必须先解决磁盘、权限或配置问题，否则任何从库修复都是徒劳。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
从库怎么恢复：不能跳过，要重设同步起点
SET GLOBAL sql_slave_skip_counter = 1 对 LOST_EVENTS 完全无效，强行执行只会让 SQL 线程跳过 incident 事件，继续读取后面可能已损坏或缺失的 binlog，导致数据错乱。正确做法是放弃当前 relay log，重新锚定到一个完好的 binlog 位置：
- 停止复制：
STOP SLAVE; - 在主库上执行
SHOW MASTER STATUS;，记下当前File和Position - 如果主库 binlog 已恢复且连续，直接在从库执行：
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.0000xx', MASTER_LOG_POS=yyyyy;，然后START SLAVE; - 如果主库 binlog 有断裂（例如
mysql-bin.000010后直接跳到mysql-bin.000012），或你不确定完整性，必须重做从库：用mysqldump --single-transaction --master-data=2导出主库全量，再导入从库并解析 dump 文件中的CHANGE MASTER TO语句
注意：GTID 模式下不能靠 gtid_next 跳过此错误，因为 LOST_EVENTS 不属于 GTID 事务范畴，它是一个元事件，GTID 机制不覆盖它。
容易忽略的细节：relay_log_recovery 必须开
很多环境没启用 relay_log_recovery=1，这会导致从库崩溃重启后 relay log 不完整，SQL 线程从损坏的中继日志开头重放，极大概率再次触发 LOST_EVENTS 类错误。务必在从库配置中加入：
relay_log_recovery = ON
它会让从库启动时自动丢弃未完成的 relay log，重新从 master 获取最新 binlog，避免残留损坏日志干扰。这是生产环境从库的必备安全项，不是可选项。
