从库 binlog 不能直接恢复主库数据，因其默认关闭或仅记录本地语句；唯有主库 binlog 或开启 log_slave_updates=on 的从库 binlog 可用，且该配置须提前启用。
从库 Binlog 不能直接恢复主库数据
MySQL 从库的 binlog 默认是关闭的（log_bin=OFF），即使开了，记录的也是从库自己执行的语句（比如 INSERT、UPDATE），不是主库原始的写入事件。所以指望靠从库的 binlog 回滚或还原主库状态，基本走不通。
真正能用于主库恢复的，只有主库自己的 binlog —— 或者，从库开启 log_slave_updates=ON 后产生的 binlog（它会把 relay log 重放的事件再记一次）。但这个配置必须提前打开，事后无法补救。
- 检查从库是否启用：执行
SHOW VARIABLES LIKE 'log_slave_updates';，返回ON才有效 - 没开过？那从库
binlog文件里大概率只有SET @@SESSION.GTID_NEXT、BEGIN、COMMIT这类空壳事件，没实际 SQL - 误删表后想“从从库捞 binlog 恢复主库”？先确认
log_slave_updates是否长期开启，否则别浪费时间解析
中继日志（relay log）不是为恢复设计的
relay log 是从库临时缓存主库 binlog 事件的中间文件，格式和主库 binlog 一致（如 mysql-relay-bin.000001），但它只保证能被 SQL 线程重放，不保证可读、可逆、可筛选。MySQL 不提供官方工具把 relay log 转成可执行的 SQL。
强行用 mysqlbinlog 解析 relay log（比如 mysqlbinlog /var/lib/mysql/mysql-relay-bin.000002）确实能出内容，但要注意：
- 事件时间戳、server-id、GTID 都是主库的，但 position 是 relay log 自己的偏移，和主库 binlog position 不对应
- 如果从库启用了
replicate_rewrite_db或过滤规则，relay log 里的库名/表名可能已被改写 - 遇到
STOP SLAVE后又START SLAVE，relay log 会轮转，旧文件可能被自动清理（受relay_log_purge=ON和expire_logs_days控制）
真要靠从库恢复主库，只有一条路：用 relay log + 主库 binlog position 对齐
前提是：主库崩溃前最后的 binlog position 已知（比如从 SHOW MASTER STATUS 或备份时记录），且从库 IO 线程没丢事件（Seconds_Behind_Master = 0，Read_Master_Log_Pos == Exec_Master_Log_Pos）。
操作本质是“把从库已拉取但未重放的 relay log 补到主库”，步骤极简但容错低：
- 停从库：
STOP SLAVE;，防止 relay log 继续追写 - 查当前位置：
SHOW SLAVE STATUS\G，重点关注Relay_Master_Log_File和Exec_Master_Log_Pos - 用
mysqlbinlog提取该文件从Exec_Master_Log_Pos开始的事件：mysqlbinlog --start-position=123456 /var/lib/mysql/mysql-relay-bin.000003 > patch.sql - 手动清理
patch.sql里的# at注释、SET @@SESSION、/*!*/杂项，只留INSERT/UPDATE等 DML - 在主库执行：
mysql -u root db_name
这方法脆弱点在于：一旦从库 SQL 线程出错跳过事件，或者主库 binlog 被 purged，position 就对不上，补的数据可能重复或遗漏。
为什么别依赖从库日志做主库恢复
核心矛盾就一个：从库日志的完整性、可追溯性、可审计性，都弱于主库 binlog。主库 binlog 是源头，有完整 GTID 链、精确时间戳、可控的格式（STATEMENT/ROW）、保留策略明确；从库的 relay log 和（非 log_slave_updates 下的）binlog，只是复制链路上的副产品。
真正该做的，是确保主库 binlog 开启、定期备份、并用 mysqlbinlog --base64-output=DECODE-ROWS -v 验证内容可读。从库日志唯一稳妥用途，是排查复制延迟或中断原因，不是兜底恢复手段。
线上环境见过太多人翻遍从库 mysql-relay-bin.* 目录，结果发现 last relay log 早被 purge，或者解析出来全是 SET INSERT_METHOD=FIRST 这种无效语句——花半天做的事，不如主库上一句 mysqlbinlog --stop-datetime="2024-04-01 10:00:00" | mysql 来得实在。
