mysql问题之slow log中出现大量的binlog dump记录的解决方法

线上有个数据库，在slow log中，存在大量类似下面的记录：

代码如下:

# Time: 130823 13:56:08
# User@Host: repl[repl] @ slave [10.x.x.x]
# Query_time: 9.000833 Lock_time: 0.000000 Rows_sent: 1 Rows_examined: 1
SET timestamp=1377237368;
# administrator command: Binlog Dump;

每完成一次binlog dump都会被记录下来，看着非常不爽（我有强迫症，O(∩_∩)O哈哈~），得想着法子搞掉。
经过排查，最后确认是特定版本存在这个现象，目前发现官方 5.1.49 存在，估计整个官方 5.1.x 都会有这个现象。

解决方法：

修改 my.cnf 配置文件，增加或修改下面这个选项：

代码如下:

log-slow-admin-statements = 0

比较坑人的是，这个选项在5.1无法在线修改，需要重启mysqld。
手册上关于这个选项的解释如下：

代码如下:

Include slow administrative statements in the statements written to the slow query log. Administrative statements include ALTER TABLE, ANALYZE TABLE, CHECK TABLE, CREATE INDEX, DROP INDEX, OPTIMIZE TABLE, and REPAIR TABLE.

手册也有不靠谱的时候啊，还是实践出真知。

赞 (0)

相关推荐

  • mysql对binlog的处理说明

    然而这里不打算对某种存储引擎的实现细节进行描述,也不打算介绍各种存储引擎的优缺点,只是描述一下mysql如何处理binlog,并澄清几个容易混淆的问题. Binlog对mysql而言是重要的,主要体现在它的功能上.Mysql官方文档明确指出,binlog的启动大概会为mysql增加1%的负载,因此在绝大多数情况下,binlog都不会成为mysql的性能瓶颈. Binlog是mysql以二进制形式打印的日志,它默认不加密,不压缩.每个正常的binlog文件头部,有4个字节的标记,值为0xfe 0x

  • 教你自动恢复MySQL数据库的日志文件(binlog)

    如果MySQL服务器启用了二进制日志,你可以使用mysqlbinlog工具来恢复从指定的时间点开始 (例如,从你最后一次备份)直到现在或另一个指定的时间点的数据."mysqlbinlog:用于处理二进制日志文件的实用工具". 要想从二进制日志恢复数据,你需要知道当前二进制日志文件的路径和文件名.一般可以从选项文件(即my.cnf or my.ini,取决于你的系统)中找到路径.如果未包含在选项文件中,当服务器启动时,可以在命令行中以选项的形式给出.启用二进制日志的选项为 --log-b

  • Linux上通过binlog文件恢复mysql数据库详细步骤

    Linux上通过binlog文件恢复mysql数据库详细步骤

     一.binlog 介绍 服务器的二进制日志记录着该数据库的所有增删改的操作日志(前提是要在自己的服务器上开启binlog),还包括了这些操作的执行时间.为了显示这些二进制内容,我们可以使用mysqlbinlog命令来查看. 用途1:主从同步 用途2:恢复数据库(也是线上出现一次数据库文件丢失后,才对这个有所了解并学习的) mysqlbinlog命令用法:shell> mysqlbinlog [options] log_file ... <!--[if !supportLists]-->

  • MySQL binlog 远程备份方法详解

    以前备份binlog时,都是先在本地进行备份压缩,然后发送到远程服务器中.但是这其中还是有一定风险的,因为日志的备份都是周期性的,如果在某个周期中,服务器宕机了,硬盘损坏了,就可能导致这段时间的binlog就丢失了. 而且,以前用脚本对远程服务器进行备份的方式,有个缺点:无法对MySQL服务器当前正在写的二进制日志文件进行备份.所以,只能等到MySQL服务器全部写完才能进行备份.而写完一个binlog的时间并不固定,这就导致备份周期的不确定. 从MySQL5.6开始,mysqlbinlog支持将

  • Mysql Data目录和 Binlog 目录 搬迁的方法

    如果全过程使用的是Mysql用户,应该可以正常启动. 如果用的ROOT用户,可能不能正常启动,原因是新建的目录权限不对. 可能会这样的错误提示: /usr/local/mysql/libexec/mysqld: File '/home/mysql/mysqllog/binlog/mysql-bin.index' not found (Errcode: 2) 1. stop mysql service 一定要先停止,非常重要. # /etc/init.d/mysqld stop 2. 修改Mysq

  • MySQL数据库恢复(使用mysqlbinlog命令)

    1:开启binlog日志记录 修改mysql配置文件mysql.ini,在[mysqld]节点下添加 复制代码 代码如下: # log-bin log-bin = E:/log/logbin.log 路径中不要包含中文和空格.重启mysql服务.通过命令行停止和启动mysql服务 复制代码 代码如下: c:\>net stop mysql; c:\>net start mysql; 进入命令行进入mysql并查看二进制日志是否已经启动 Sql代码 复制代码 代码如下: mysql>sho

  • MySQL binlog中的事件类型详解

    MySQL binlog记录的所有操作实际上都有对应的事件类型的,譬如STATEMENT格式中的DML操作对应的是QUERY_EVENT类型,ROW格式下的DML操作对应的是ROWS_EVENT类型. 首先,看看源码中定义的事件类型 源码位置:mysql-5.7.14/libbinlogevents/include/binlog_event.h enum Log_event_type { /** Every time you update this enum (when you add a ty

  • 在MySQL中使用mysqlbinlog flashback的简单教程

    简介: mysqlbinlog flashback功能是淘宝彭立勋(http://www.penglixun.com/)的一个很强劲的作品． 主要功能: 对rows格式的binlog可以进行逆向操作．delete反向生成insert, update生成反向的update,insert反向生成delete．让dba同学们也有机会简单的恢复数据．可恢复:insert, update,delete相关的操作． 演示一下使用过程: 生成带有flashback mysqlbinlog 工具: 项止主页:h

  • [MySQL binlog]mysql如何彻底解析Mixed日志格式的binlog

    mysql binlog3种格式,row,mixed,statement. 解析工作 mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.000144 |more --base64-output=DECODE-ROWS: 会显示出row模式带来的sql变更. -v :显示statement模式带来的sql语句 复制代码 代码如下: [mysql@002tmp]$ mysqlbinlog --base64-output=DECODE-ROWS

  • 当mysqlbinlog版本与mysql不一致时可能导致出哪些问题

    当mysqlbinlog版本与mysql不一致时可能导致出哪些问题

    首先要确定当前版本是不是mysqlbinlog版本,当不是mysqlbinlog版本时可能会导致出哪些问题,下面通过模拟场景的方法给大家做介绍,希望对大家有所帮助. 看当前mysqlbinlog版本的方法: mysqlbinlog --version mysqlbinlog Ver 3.3 for Linux at x86_64 场景1:mysql服务器为mysql 5.6,要求mysqlbinlog版本为3.4及以上,否则mysqlbinlog解析时会直接报错,之前已经碰到过很多次,但是没有记

  • MySQL中的binlog相关命令和恢复技巧

    操作命令: 复制代码 代码如下: show binlog events in 'mysql-bin.000016' limit 10; reset master 删除所有的二进制日志flush logs  产生一个新的binlog日志文件 show master logs; 或者 show binary logs; 查看二进制文件列表和文件大小 复制代码 代码如下: ./mysqlbinlog --start-datetime="2012-05-21 15:30:00" --stop-

随机推荐