MySQL的binlog过大导致磁盘报警


=Start=

缘由:

在启用MySQL的主从复制之后,发现在Master上的MySQL磁盘占用迅速上升导致磁盘报警(主要是mysql-bin.000xyz文件,也就是俗称的binlog文件):

$ sudo du -sh /var/lib/mysql/* | sort -hr
3.3G /var/lib/mysql/ibdata1
1.1G /var/lib/mysql/mysql-bin.000001
1.1G /var/lib/mysql/mysql-bin.000002
...
参考解答:
可能的原因:

原因一:
启用了MySQL的binlog记录(在配置文件中设置了 log-bin=mysql-bin)

原因二:
将binlog_format设置为了mixed或row(默认的格式为statement):

binlog_format = mixed
或
binlog_format = row
解决办法:

0.在不需要binlog的情况下,可以通过注释「log-bin=mysql-bin」这一行来关闭该功能;

1.修改 binlog_format = statement (占用空间相对 row 和 mixed 来说会比较小),但是对于某些SQL来说可能就不支持,需要改SQL;

2.临时删除部分binlog

mysql> PURGE BINARY LOGS TO 'mysql-bin.000039';
或
mysql> PURGE BINARY LOGS BEFORE '2016-09-20 22:46:26';

3.在配置文件my.cnf中设置 binlog 定期删除选项(修改后需要重启MySQL)

expire_logs_days = 2

4.修改MySQL的数据目录

将MySQL的数据目录修改至一个有更大空间的磁盘上,并设置 expire_logs_days 选项,避免磁盘报警。

参考链接:

=END=

,

《 “MySQL的binlog过大导致磁盘报警” 》 有 6 条评论

  1. kingbus简介
    https://github.com/flike/kingbus/blob/master/docs/cn/architecture.md
    `
    kingbus是一个基于raft强一致协议实现的分布式MySQL binlog 存储系统。它能够充当一个MySQL Slave从真正的Master上同步binglog,并存储在分布式集群中。同时又充当一个MySQL Master将集群中的binlog 同步给其他Slave。 kingbus具有如下特性:

    · 兼容MySQL 复制协议,通过Gtid方式同步Master上的binlog,同时支持slave通过Gtid方式从kingbus拉取binlog。
    · 跨地域数据复制,kingbus通过raft协议支持跨地域间的数据复制。写入到集群的binlog数据在多个节点间保证强一致,并保证binlog顺序与master上完全一致。
    · 高可用,由于kingbus是构建在Raft强一致协议之上,能够实现集群中过半数节点存活的情况下,整个binlog拉取和推送服务高可用。
    `

  2. MySQL Binlog 解析工具 Maxwell 详解
    https://mp.weixin.qq.com/s?__biz=MzI1NDU0MTE1NA==&mid=2247483882&idx=1&sn=4e4659d1c09fdc33abd9d749acff973d
    https://github.com/zendesk/maxwell
    `
    Maxwell是一个能实时读取MySQL二进制日志binlog,并生成 JSON 格式的消息,作为生产者发送给 Kafka,Kinesis、RabbitMQ、Redis、Google Cloud Pub/Sub、文件或其它平台的应用程序。它的常见应用场景有ETL、维护缓存、收集表级别的dml指标、增量到搜索引擎、数据分区迁移、切库binlog回滚方案等。

    除了Maxwell外,目前常用的MySQL Binlog解析工具主要有阿里的canal、mysql_streamer,三个工具对比如下:
    Canal 由Java开发,分为服务端和客户端,拥有众多的衍生应用,性能稳定,功能强大;canal 需要自己编写客户端来消费canal解析到的数据。
    maxwell相对于canal的优势是使用简单,它直接将数据变更输出为json字符串,不需要再编写客户端。
    `

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注