☰

为什么 MySQL 要写入数百个 125 字节的二进制日志文件？

tag-icon • tag-icon mysql logging replication binary slave
为什么 MySQL 要写入数百个 125 字节的二进制日志文件？

我的 MySQL Master（现在没有连接的从属服务器）大约每分钟写出一个 125 字节的文件：

-rw-rw---- 1 mysql mysql        125 2012-12-28 16:46 snapshot-mysql-v2-bin.004876
-rw-rw---- 1 mysql mysql        125 2012-12-28 16:45 snapshot-mysql-v2-bin.004875
-rw-rw---- 1 mysql mysql        125 2012-12-28 16:43 snapshot-mysql-v2-bin.004874
-rw-rw---- 1 mysql mysql        125 2012-12-28 16:41 snapshot-mysql-v2-bin.004873

同时将实际的二进制日志内容写入具有较低数字的文件中：

-rw-rw---- 1 mysql mysql  330755915 2012-12-28 16:48 snapshot-mysql-v2-bin.004472

（当该文件写满时，它会转到下一个文件）。

此外，MySQL 不会将包含内容的实际文件的名称（上面的 004472）写入 .index 文件，因此当我连接从属服务器时，它无法复制，直到我手动编辑 .index 文件。

MySQL版本是5.1.41-3ubuntu12.10-log。

有任何想法吗？

答案1

问题似乎是 /var/lib/mysql/ibdata1 文件被锁定，MySQL 无法写入。尽管 MySQL 服务器运行良好（并且向 InnoDB 表添加了大量行），但我在 mysql.err 文件中发现了很多与此相关的条目。

为了修复它，我必须关闭所有 mysqld 实例（mysqladmin shutdown 不足以获取它们），然后我运行：

cp -a ibdata1 ibdatanew1

我编辑了 my.cnf 以指向 ibdatanew1 文件。我再次启动了 MySQL，重置了主服务器，刷新了日志，过去 6 个小时一切正常。

我仍然不清楚被锁定的 ibdata1 文件如何使 MySQL 能够继续运行，但也许 ibdata1 问题仅在写入二进制日志时出现？（值得注意的是，我习惯在 mysqld.log 中看到 ibdata1 问题，而不是 mysql.err 日志中）。

相关内容