典型场景是：
- 主库事务提交时 binlog 已经写到 OS page cache 或 MySQL binlog 文件缓冲；
- binlog dump 线程已经把这些 event 发给从库；
- 从库 IO/SQL 线程收到并执行；
- 从库开启了 log_slave_updates，所以这些 event 又写进了从库自己的 binlog；
- 随后主库宕机；
- 由于主库 sync_binlog != 1，或者底层存储/文件系统没有真正持久化，主库恢复后 binlog 被截断或丢失尾部 event。
这时就会看到：从库 binlog 有这些事务，但主库当前 binlog 文件没有。
所以一句话结论是：
“主库写过但未持久化，复制已发出，主库 crash 后 binlog 丢了，而从库保留了”是可能的。
如果你是在排查真实故障，重点看这些配置和证据：
- 主库 sync_binlog
- 主库 innodb_flush_log_at_trx_commit
- 是否开启半同步，以及 rpl_semi_sync_source_wait_point
- 主库是否发生过 crash/restart
- 主库 error log 是否有 binlog truncation / crash recovery 记录
- 从库 relay log / binlog 中 event 的 GTID 或 position 是否超过主库当前 binlog 末尾
