最可靠方式是执行 show master status；file 为当前 binlog 文件名（如 mysql-bin.000012），position 为下一个待写入事件偏移量（重启或轮转后重置为4）。
如何查 MySQL 主库的 binlog 文件名和位置
主库的 binlog 文件名和当前写入位置，直接决定从库 IO 线程该从哪读、从哪起同步。最可靠的方式是登录主库执行：
SHOW MASTER STATUS;返回结果中
File 是当前活跃的 binlog 文件名（如 mysql-bin.000012），Position 是该文件内下一个待写入事件的偏移量（不是最后一条已写入的位置）。注意：这个 Position 值在主库重启或日志轮转后会重置为 4（因为每个 binlog 文件开头固定有 4 字节 magic number），不能跨文件直接用。
binlog 文件实际存储路径怎么确认
MySQL 不一定把 binlog 写在数据目录下，具体位置由配置项 log_bin 决定。查法有两种：
- 登录 MySQL 执行
SELECT @@log_bin, @@log_bin_basename;
——如果@@log_bin为ON，则@@log_bin_basename的值就是完整路径前缀（例如/var/lib/mysql/mysql-bin），实际文件就是/var/lib/mysql/mysql-bin.000001这类 - 检查 MySQL 配置文件（
my.cnf或mysqld.cnf）里是否有log_bin = /path/to/mysql-bin，该路径优先级高于数据目录
常见误区：误以为 datadir 就是 binlog 路径；实际上若没显式配置 log_bin，MySQL 才会默认用 datadir 下的主机名 + -bin 命名（如 server1-bin.000001），但该行为不可靠，尤其在容器或云数据库中往往被覆盖。
mysqlbinlog 工具怎么安全解析 binlog 文件
mysqlbinlog 是离线解析 binlog 的唯一标准工具，但它不连接数据库，只读取磁盘文件，因此必须确保：
- 运行用户对 binlog 文件有读权限（常因权限问题报错
Failed to open file 'mysql-bin.000012'） - 使用与生成该 binlog 的 MySQL 版本尽量一致的
mysqlbinlog，否则可能解析失败或跳过部分事件（尤其是 GTID、行格式变更等） - 加
--base64-output=DECODE-ROWS -v才能看清行级变更；仅-v只显示语句级事件，且对 ROW 格式输出乱码 - 避免直接用
mysqlbinlog mysql-bin.000012 | mysql -u...回放——缺少事务边界控制，极易破坏一致性；应先导出为 SQL 文件，人工过滤后再导入
从库 relay log 文件位置和状态怎么看
从库的中继日志（relay log）是 IO 线程从主库拉取后暂存的副本，位置由 relay_log 配置项控制，默认在数据目录下，文件名形如 hostname-relay-bin.000001。查当前状态用：
SHOW SLAVE STATUS\G重点关注：
Relay_Log_File（当前正在写的 relay log）、Relay_Log_Pos（该文件内已执行到的位置）、Relay_Master_Log_File（对应主库哪个 binlog 文件）、Exec_Master_Log_Pos（对应主库 binlog 内已执行到的位置）。这四个值共同构成复制坐标，缺一不可；任意一个异常（比如 Relay_Log_Pos 比 Relay_Log_File 文件大小还大），说明 relay log 损坏或 IO 线程卡住。
真正难处理的是 binlog 和 relay log 的生命周期管理：它们不会自动清理，除非配置了 expire_logs_days 或手动 PURGE BINARY LOGS；而从库上 PURGE RELAY LOGS 必须确保 SQL 线程已执行完对应事件，否则会导致复制中断——这点容易被忽略，尤其在延迟大的从库上强行清理 relay log 会直接触发 Relay log read failure 错误。
