要确认主库 binlog 是否正常启用并可用于复制，需分三步验证：开启状态、当前日志位置、日志内容可读性。不能只看“开了没”，还要确保从库能连上、能读取、能解析。
检查 binlog 是否已启用
登录 MySQL 主库执行：
SHOW VARIABLES LIKE 'log_bin';
返回结果中 Value 必须为 ON。若为 OFF，说明 binlog 未启用，主从复制无法进行。同时建议一并检查：
SHOW VARIABLES LIKE 'log_bin_basename';<br>SHOW VARIABLES LIKE 'binlog_format';<br>SHOW VARIABLES LIKE 'server_id';
其中：
• log_bin_basename 显示 binlog 文件实际存储路径和前缀；
• binlog_format 推荐为 ROW 或 MIXED（STATEMENT 在某些函数/非确定语句下可能复制失败）；
• server_id 必须非零且在集群中唯一，否则从库拒绝连接。
确认当前 binlog 文件与写入位置
运行：
SHOW MASTER STATUS\G
输出关键字段：
File：当前正在写入的 binlog 文件名（如mysql-bin.000012） Position：该文件内最新事件的结束位置（即下一个事件将从此 position 开始写入） Binlog_Do_DB / Binlog_Ignore_DB：确认是否意外过滤了需要复制的数据库
该命令结果是主库向从库提供同步起点的依据。从库执行
CHANGE REPLICATION SOURCE TO ...时必须匹配这里的 File 和 Position（或 GTID）。
验证 binlog 内容可读且连续
先列出所有可用 binlog：
SHOW BINARY LOGS;
再选一个较新的文件查看开头几条事件（避免全量加载）：
SHOW BINLOG EVENTS IN 'mysql-bin.000012' LIMIT 5;
观察是否有合法的
Query、
Write_rows、
Update_rows等事件类型，时间戳是否连续，没有 ERROR 或 corruption 提示。若报错 “Could not open log file” 或 “Not a binary log file”，说明文件损坏或路径错误。
更可靠的方式是用 mysqlbinlog 工具解析（尤其排查复制中断时）：
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000012 | head -n 30
可清晰看到表名、字段变更（@1=@2=…）、事务边界 BEGIN/COMMIT，确认数据变更逻辑符合预期。
辅助检查项（复制链路完整性）
除了 binlog 本身，还需确认主库未阻塞复制相关操作：
执行SHOW PROCESSLIST;，查找是否有长时间运行的
Binlog Dump线程（表示从库正连接拉取日志） 检查磁盘空间：
df -h查看 binlog 所在分区是否快满（满则自动停写，
log_bin变为 OFF） 确认没有误执行
RESET MASTER;（会清空所有 binlog 并重置 index，导致从库断连）
