Mysql 二进制日志未旋转,分区空间不足,复制相关的管理查询挂起

Mysql 二进制日志未旋转,分区空间不足,复制相关的管理查询挂起

我有一个盒子,其根分区已满。

最直接的解释是 mysql 二进制日志没有轮换。尽管 expire_log_days 设置为 10,但仍有超过 10 天的日志。show master status、、show slave statuspurge binary logs全部无限期挂起。

答案1

我会尝试一些方法,但请确保 / 已满是您的问题。通常,Mysql 将数据存储在 /var/lib/mysql 中,除了 /tmp 之外,不会将 / 用于其他用途。

首先尝试清理一些空间。从 /var/log/ 中删除旧日志,或者删除您下载但从未使用过的 src 代码。如果您可以将 / 降低到 100% 以下,Mysql 可能会返回到未卡住的状态。

假设您已经清理了一些空间,请尝试清除日志。我会尝试从 Mysql 命令行执行 PURGE BINARY LOGS BEFORE DATE_SUB( NOW( ), INTERVAL 3 DAY);。如果十分钟后它仍然挂起,您可能需要关闭 Mysql(如果可以的话)或将其杀死(如果不能的话)。

通常情况下,手动删除日志不是一个好主意,但在这种情况下,这可能是你唯一的选择。删除最旧的日志并尝试重新启动 Mysql。它可能必须进行一些表检查。密切关注 mysql 错误日志,直到它正常运行。然后尝试再次清除日志。

一旦启动并运行,请通过检查 Mysql 中的 show variable; 确保 expire_logs_days 确实已设置。如果您的文件系统较小,您可能还需要设置 max_binlog_size = 100M。通常,Mysql 以 1G 为单位轮换日志,这可能不够频繁。Mysql 仅在当前日志达到最大大小时轮换日志。

答案2

这完全取决于你运行的 MySQL 版本

问题在于所有二进制日志的内存映射。

当mysqld启动时,它会将mysql二进制日志的索引读入内存。

该内存映射对磁盘上二进制日志的存在很敏感。

如果您执行以下命令:
1. PURGE BINARY LOGS TO '< 二进制日志文件名 >';
2. PURGE BINARY LOGS BEFORE '< 日期和时间 >';
3. RESET MASTER;

mysqld 将使用内存映射而不是二进制日志索引文件。

如果内存映射与磁盘上的二进制日志文件不完全匹配(即不同步),则使用 expire_logs_days 的日志轮换将会失败。

您不能简单地编辑 mysql 二进制日志索引文件,因为当您对 mysqld 发出关闭命令时,内存映射将覆盖二进制日志索引文件。

该问题通常发生在有人删除操作系统中的二进制日志而不是使用前面提到的三个 (3) MySQL 命令之一时。mysqld 不会仅仅发现二进制日志的突然消失。

唯一可以立即纠正的方法是删除所有二进制日志,删除二进制日志索引文件,然后重新启动 mysql,或者您可以执行以下操作:

  1. 关闭mysql
  2. 删除你不想要的二进制日志
  3. 编辑二进制日志索引文件(从文件中删除不存在的二进制日志)
  4. 启动 mysqld

此后,要留意二进制日志是否消失,请运行 SHOW BINARY LOGS;如果任何二进制日志条目返回的文件大小为 0,则二进制日志的内存映射不同步。然后,应采取以下措施:

  1. 关闭mysql
  2. 编辑二进制日志索引文件(从文件中删除不存在的二进制日志)
  3. 启动 mysqld

答案3

我的建议是,一旦您将其拯救,就将 /var/lib/mysql 和 /var/log/mysql 放在它们自己的 LVM 卷上。

相关内容