MySQL binlog超过binlog_expire_logs_seconds阈值没有删除案例

这篇具有很好参考价值的文章主要介绍了MySQL binlog超过binlog_expire_logs_seconds阈值没有删除案例。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

生产环境有一套3个节点的MySQL InnoDB Cluster,MySQL的版本为Server version: 8.0.35 MySQL Community Server - GPL, 早上突然收到Zabbix的告警,其中一个节点出现空间告警:"/data: Disk space is low (used > 80%)"

检查分析后发现是因为MySQL的binlog没有清理导致空间报警,如下所示(binlog太多,省略了部分内容)

$ du -sh *
78G     bin_logs
12K     conf
7.3G    data
132K    logs
4.0K    mysql.pid
0       mysql_temp
4.0K    slow_logs
cd bin_logs
$ ls -lrt
total 81783492
-rw-r----- 1 mysql mysql  909802606 Jan  9 00:10 mysql_binlog.000011
-rw-r----- 1 mysql mysql  984228474 Jan 10 00:10 mysql_binlog.000012
-rw-r----- 1 mysql mysql  980302993 Jan 11 00:10 mysql_binlog.000013
-rw-r----- 1 mysql mysql  985147519 Jan 12 00:10 mysql_binlog.000014
-rw-r----- 1 mysql mysql  962232624 Jan 13 00:10 mysql_binlog.000015
....................................................
....................................................
-rw-r----- 1 mysql mysql  891703862 Apr  7 00:10 mysql_binlog.000101
-rw-r----- 1 mysql mysql  920700543 Apr  8 00:10 mysql_binlog.000102
-rw-r----- 1 mysql mysql  921675101 Apr  9 00:10 mysql_binlog.000103
-rw-r----- 1 mysql mysql       3854 Apr  9 00:10 mysql_binlog.index
-rw-r----- 1 mysql mysql  330341220 Apr  9 09:30 mysql_binlog.000104

检查三个节点(姑且用node1, node2, node3表示),发现其它两个节点(node1,node2)的binlog都正常清理了,而唯独节点node3的binlog一直没有被清理。三个节点的MySQL系统变量是一致的,如下所示,

mysql> show variables like 'binlog_expire_logs_seconds';
+----------------------------+---------+
| Variable_name              | Value   |
+----------------------------+---------+
| binlog_expire_logs_seconds | 1209600 |
+----------------------------+---------+
1 row in set (0.00 sec)

mysql> show variables like 'expire_logs_days';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| expire_logs_days | 0     |
+------------------+-------+
1 row in set (0.00 sec)

mysql> 

binlog_expire_logs_seconds设置为1209600,也就是14天,超过14天的binlog应该被清理掉,但是检查发现node3上超过14天的binlog并没有被清理。那么为什么节点node3上的过期的binlog没有被清理呢?

首先,这三个节点的MySQL数据库版本是一致的,出现问题的节点node3是MySQL InnoDB集群的备库,我们在这个节点上做Xtrabackup备份。

其次,我们检查MySQL错误日志,其实每天作业做Xtrabackup备份时,都会收到类似下面告警邮件

2024-04-09T00:10:03.078285+08:00 357726 [Warning] [MY-013712] [Server] No suitable 'keyring_component_metadata_query' service implementation found to fulfill the request.
2024-04-09T00:10:12.066464+08:00 357726 [Warning] [MY-014054] [Server] Could not purge binary logs since another session is executing LOCK INSTANCE FOR BACKUP. Wait for that session to release the lock.

出现这个告警信息,之前也查过,官方文档提示,当对MySQL实例发出LOCK INSTANCE FOR BACKUP语句期间,PURGE BINARY LOGS是不允许的,因为它会从服务器中删除文件(删除binlog文件),违反了备份锁(backup lock)的规则。从MySQL 8.0.28开始,这个是不允许的。具体的官方文档[1]信息如下所示:

PURGE BINARY LOGS should not be issued while a LOCK INSTANCE FOR BACKUP statement is in effect for the instance, because it contravenes the rules of the backup lock by removing files from the server. From MySQL 8.0.28, this is disallowed.

因为Xtrabackup备份时,它会执行FLUSH NO_WRITE_TO_BINLOG BINARY LOGS命令,它会轮换二进制日志(rotate the binlog),这实质上将创建一个新的二进制日志,而在 轮换二进制日志时,就会触发PURGE BINARY LOGS,而由于当前MySQL版本为MySQL 8.0.35,在MySQL进行Xtrabackup时,由于LOCK INSTANCE FOR BACKUP锁,导致PURGE BINARY LOGS是不允许的。所以Xtrabackup期间,我们会收到这个告警,即使binlog出现了轮换,但是也不会触发清理过期的binlog。之前分析过这个告警,但是觉得它没有产生什么异常或问题,就忽略了这个告警。

另外,我们要弄清楚清理过期binlog的原理机制,即使我们设置了系统变量binlog_expire_logs_seconds,不是说一旦binlog的创建时间超过了系统变的binlog_expire_logs_seconds的阈值,就会立即触发MySQL的相关线程去清理过期的binlog。清理过期的binlog,一般发生在MySQL启动时或刷新二进制日志时进行。官方文档[2]的描述如下:

Binary log files are automatically removed after the server's binary log expiration period. Removal of the files can take place at startup and when the binary log is flushed.

我检查系统变量max_binlog_size的大小,如下所示,也就是1G,

mysql> show variables like 'max_binlog_size';
+-----------------+------------+
| Variable_name   | Value      |
+-----------------+------------+
| max_binlog_size | 1073741824 |
+-----------------+------------+
1 row in set (0.01 sec)

mysql>

由于这个系统一天产生的binlog小于1G(可以从上面的binlog的输出信息看出,例如,binlog的大小,binlog的创建时间),也就是说,一天24小时内,MySQL的binlog不会由于binlog过大而触发binlog的切换,也就是说只有Xtrabackup时才触发了binlog的切换,而又由于限制问题,导致过期的binlog不能被清理,久而久之,过期的binlog一直不能清理,直到触发空间告警,问题才被暴露出来。

而其它几套MySQL InnoDB Cluster也有这个问题,但是它们的过期的binlog为什么被清理了呢? 因为它们一天产生的binlog的大小,超过了系统变量max_binlog_size的大小,在其它时间点会轮换/切换binlog,从而触发了PURGE BINARY LOGS。所以就没有遇到这样的问题。

参考资料

[1]

1: https://dev.mysql.com/doc/refman/8.0/en/lock-instance-for-backup.html

[2]

2: https://dev.mysql.com/doc/refman/8.0/en/purge-binary-logs.html文章来源地址https://www.toymoban.com/news/detail-848175.html

到了这里,关于MySQL binlog超过binlog_expire_logs_seconds阈值没有删除案例的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • mysql undo log、redo log、binlog、mvcc、Buffer Pool的关系

            MySQL中的undo log、redo log、binlog和MVCC(多版本并发控制)是数据库管理系统中的 重要概念,它们各自有不同的作用和关系。 Buffer Pool(缓冲池): 作为InnoDB存储引擎的核心组件,Buffer Pool用于缓存从磁盘读取的数据页。所有的数据修改首先发生在内存中的缓冲池里

    2024年02月02日
    浏览(41)
  • mysql-bin日志清理,并设置expire_logs_days时间,mysql占用空间过大问题

    mysql-bin日志清理,并设置expire_logs_days时间,mysql占用空间过大问题 最近发现生产环境的服务器磁盘空间吃紧,查下到底是哪里占用的空间比较大,最后发现,mysql占用空间蛮大的。 发现mysql占用的空间很大,具体看看哪些数据占用了空间 发现mysql-bin占用了很大的空间 mysql-b

    2024年02月01日
    浏览(47)
  • 02_重要的两个日志 redo log 和 binlog

    MySQL 45 讲Note: 课程专栏名称:《MySQL实战45讲》课程 笔记参考:MYSQL45 讲 想要理解这两个日志 redo log 和 binlog ;我们需要对MySQL 的备份恢复机制有一个基本的了解。 之前你可能经常听 DBA 同事说,MySQL 可以恢复到半个月内任意一秒的状态,带着好奇的态度,这是怎样做到的呢

    2024年02月07日
    浏览(39)
  • innodb_flush_log_at_trx_commit 和 sync_binlog 参数解析

    这两个参数和MySQL的一致性以及性能相关,默认配置大多数情况下不是最优的。一般来说,互联网线上系统的配置: innodb_flush_log_at_trx_commit —— 0 sync_binlog —— 1000 如果我们想要提交一个事务了,会根据一定的策略把 redo 日志从 redo log buffer 刷入到磁盘文件里去。通过 innod

    2024年02月03日
    浏览(30)
  • 取出/var/log/secure中一小时内登录失败超过三次的IP

    取出/var/log/secure中一小时内登录失败超过三次的IP 前两个字段是日期,第三个字段是小时,第四个字段是IP cat /var/log/secure | sort -i | awk -F \\\'[ :]\\\' \\\'/Failed/{a[$1\\\" \\\"$2\\\" \\\"$3\\\" \\\"$4\\\" \\\"$(NF-3)]++}END{for(i in a)if(a[i]3)print i}\\\'   s=\\\"Jul 7 13:49:08\\\" sed -n \\\"/$s/,$ p\\\" /var/log/secure | awk \\\'/Failed/{a[$(NF-3)]++}END{for(b i

    2024年04月15日
    浏览(33)
  • mysql8关闭binlog并清空Binlog

    编辑my.ini或者my.cnf文件 清空binlog信息 停用binlog功能 为啥要关闭binlog功能呢? 是因为反正是个测试服务器,磁盘比较小。无所谓数据丢不丢的。但是不建议生产环境关闭,这可能会造成非常严重的灾难。 在mysqld分组下面加skip-log-bin配置 然后重启数据库即可 重启后查询log_bin状

    2024年02月09日
    浏览(43)
  • MySQL 开启配置binlog以及通过binlog恢复数据

       binlog是MySQL sever层维护的一种二进制日志,binlog是记录所有数据库表结构变更(例如CREATE、ALTER TABLE、DROP等)以及表数据修改(INSERT、UPDATE、DELETE、TRUNCATE等)的二进制日志。不会记录SELECT和SHOW这类操作,因为这类操作对数据本身并没有修改。 作用主要有: 主从复制:在

    2024年02月03日
    浏览(55)
  • mysql关闭binlog日志,删除binlog数据(win和linux通用)

    打开 mysql 命令窗口,查询 binlog 是否开启   (ON)为开启状态 (OFF)为关闭状态 若开启状态则需要修改配置文件,反之不需要任何操作 在 C:ProgramDataMySQLMySQL Server 8.0 路径下打开 my.ini 并注释掉 bin-log 配置项然后在其后面加入skip-log-bin   重启mysql服务   打开 mysql 命令窗口,

    2024年02月07日
    浏览(38)
  • mysql的binlog日志

    一、查看和配置binlog 1、log_bin 是否开启binlog,指定日志文件路径 2、log_bin_basename 和 log_bin_index 日志文件基础名和索引名(*好像不能用来设置只是展示作用,我设置时时会报错无法启动服务) 3、binlog_format 日志格式 4、binlog_error_action 设置当binlog日志数据一致性遭到破坏或者复

    2024年02月16日
    浏览(38)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包