这个问题是笔者第一次遇到，从问题的现象看，binlog 是没有问题的，可以正常写入和切换，只是 show 命令看不到 binlog 文件列表，我们知道 MySQL 是用一个 index 元文件来维护当前使用的 binlog 的，而 也是读这个文件来展示的，因此问题应该出在 index 文件上。

我们首先检查 index 文件的权限，发现也是没问题的，mysqld 进程用户是有读写权限的，然后我们用 tail -f 命令监控 index 文件，另一个窗口连接mysql，执行 flush binary logs，发现新产生的 binlog 文件也是会追加到 index 里。越排查越觉得诡异，并且没有排查下去的思路了，难道是 逻辑有问题，翻开代码确认了下，主体逻辑非常简单，就是从 index 文件头开始遍历，一行对应一个 binlog 文件，每一个 binlog 文件都获取下文件size，然后把结果发给客户端，详见 rpl_master.cc:show_binlogs():

有没有看出什么？

细心的读者可能已经发现，第一行是空行，再看下刚的代码，有这么一个判断逻辑:

解法很简单，删了第一行的空行，然后 flush binary logs 生成新的 index 文件把 cache 失效掉，就可以了。

那么下一个问题来了，为什么第一行会是个空行呢，因为之前主机磁盘被堆满，为了快速清出空间，运维同学把一些老的 binlog 清理掉了，同时 “贴心的” 的把 index 文件也同步手动编辑了，但是因为手残留下了一个空行。。。

从这个问题我们也可以看出，MySQL 在有些时候的逻辑处理非常粗糙简单，对于文件格式没有适当地检测机制，像这种诡异问题就被隐藏吞没掉。如果翻看 commit 历史的话，可以看到“空行就认为是文件结束”的逻辑，在2002年之后就一直是这样的了:-(