2014中华数据库与运维安全大会介绍

【导读】
自2009年于上海举办技术会议以来,一直坚持公益性且技术干货为主的特点,在2009年至2011年底之间的三年期间一直是IT168坚持真诚奉献,后因公司被收购等因素不得不放弃华东地区的免费技术活动,自接手技术会议以来,得到很多朋友和企业的支持,使我们华东地区的技术会议得以继续举办,并且一届比一届更好。随着会议规模的扩大,其他地区的(尤其是华南地区和华北地区)会议参与者逐年增加,在2013年11月16日,正式更名会议为中华架构师大会,以及中华数据库与运维安全大会。2014年5月24日,我们将在上海举办2014中华数据库与运维安全大会,精彩内容请勿错过。

【会议介绍】
2014年05月24日(星期六)07:45至19:00,我们将在上海市虹口区纪念路301号宝丰联大酒店举办一年一度的中华数据库与运维安全大会。届时来自百度、腾讯、阿里巴巴、网易、大众点评、人人网、圆通速递、CNTV、淘宝、支付宝等技术精英们,将以他们的成功实践经验,为我们带来关于数据库、运维自动化、运维安全、互联网金融、架构设计等等的技术分享盛宴。本届会议官方报名网站:http://meeting.zhdba.com/2014dtcc

【会议信息】

会议时间:2014年05月24日 (1天,上午1个主会场,下午2个分会场,共计14个精彩主题)
会议地点:上海市虹口区纪念路301号宝丰联大酒店水晶厅,牡丹厅
报名人数:预计2000人
预计出席人数:1200人(注:依据往届会议的出席比例经验)
会议座席:主会场1200个,分会场650个(预留了80个VIP席位,给赞助企业、演讲嘉宾、捐助者 、捐助企业)
报名截止日期:2014年03月15日,关闭免费报名渠道,逾期报名收费

【嘉宾信息】

主持人:余锋

嘉宾简介:
阿里巴巴集团核心系统部数据库组资深专家,先后在网易,迅雷,网龙等国内知名的IT企业从事研究和开发工作。有超过15年的网络、内核以及底层软件开发经验,专注于高性能分布式服务器的研究和实现,擅长构建大规模集群服务器,对NoSQL系统和分布式文件存储有深入的研究和实践,同时致力于Erlang分布式系统的研究和推广。目前负责阿里RDS云和相关的数据库分支。

 


主持人:洪倍

嘉宾简介:
洪倍,AdMaster联合创始人兼CTO
2003年毕业于上海交大计算机系,2006年和闫曌一起创立AdMaster精硕科技,担任CTO。 八年来带领 AdMaster 架构了涵盖互联网广告、移动广告、社交舆情、在线调研、电商渠道管理等数字营销核心领域的大数据平台; 在分布式计算、数据挖掘和系统架构领域有丰富的实战经验。

演讲嘉宾:刘宇

嘉宾简介:刘宇就职于百度, 担任运维专家。是《Puppet实战》一书的作者,linuxtone.org 创造人之一。
演讲主题:Puppet给运维带来的变革
内容摘要:
1 纵谈运维
1.1 传统的运维
1.2 现在的运维及未来趋势
1.3 运维系统化(将监控、部署、发布、都融合至平台)
1.4 运维的机遇及挑战(云计算的挑战,需要支持快速部署等)
1.5 工具在这股浪潮中带来的变化(各种开源工具,可以列出一些表格)
1.6 基础设施在运维中的重要性(变更与底层一致性)
2 Puppet应用
2.1 什么是Puppet? (Puppet有那些特性,DSL比较自由)
2.2 Puppet能做什么?(管理软件包、文件、服务、脚本等)
2.3 例子:管理一个文件
2.4 依赖关系
2.5 什么是Facter
2.6 什么是Class,及继承
2.7 什么是Node
2.8 模板及结果输出
2.9 Puppet成套的产品(语法检查,文档输出,依赖关系图,DB写入,报告展示)

演讲嘉宾:宋利兵

嘉宾简介:就职于ORACLE。2009年加入MySQL Replication研发团队,4年多来一直在从事MySQL Replication的研发工作。目前主要负责MySQL Replication新功能和性能提升方面的工作.
演讲主题:深入理解MySQL Replication
内容摘要:MySQL Replication的结构、模块和原理的介绍,以及MySQL 5.7 Replication新功能的介绍。

演讲嘉宾:何登成

嘉宾简介: 何登成,网易杭州研究院技术专家,技术爱好者,在数据库、并发编程、性能优化等领域,有一定的经验积累。平时通过个人微博,帐号:何_登成,或者个人网站http://hedengcheng.com,进行技术分享与交流。
演讲主题:深入MySQL源码 — Step By Step
内容摘要:MySQL,作为一个开源的数据库产品,在国内获得越来越多的重视,也有越来越多技术人员接触、使用MySQL。甚至有些公司或者个人,提出了更高的要求:研究MySQL的源码,做定制化的功能。本次演讲,从作者自身的经验出发,分享一些作者在研究、学习MySQL源码过程中所使用的方法,希望对有志于投身到MySQL源码学习的朋友,有所帮助。

演讲嘉宾:楼方鑫

嘉宾简介: 楼方鑫,OracleACE,Oracle恢复软件AUL和Oracle文本导出软件sqluldr2的作者,曾在eBay运维团队工作,现就职于支付宝。多年高并发高压力数据库管理经验,善长数据库性能及系统调优,数据库监控,故障处理,容量分析与规划。开发有多款流行的DBA工具,原创的Oracle数据库恢复软件AUL,为全球20个以上不同国家的客户提供过数据恢复服务。多年管理高并发(5000以上数据库会话)的大型(2TB以上)数据库的经验,着重于自动化工具开发,性能调优,系统监控及数据库容量规划等工作。2013年中,在深厚的Oracle基础之上开始研读MySQL源代码,在MySQL性能改善及数据保护方面,取得十分有效的进展!

演讲主题:MySQL的性能改进之路

内容摘要:MySQL也可以取得很高的性能,了解MySQL性能问题的关键之处,就可以合理地避免MySQL全局锁带来的SYS CPU争用,从而发挥最佳的性能,达到和Oracle差不多的性能。通过自己研究的类Thread Pool机制和其他方面的优化,大幅度地降低了SYS CPU的利用率,让机器的CPU全部用于业务请求,而不是花在内部并发及资源锁的竞争之中,主要介绍我个人对MySQL性能优化方面的考虑和改进思想。

演讲嘉宾:古雷

嘉宾简介: 古雷,2007年加入搜狐网络运营部DBA团队;2014年初加入搜狐畅游mobogenie项目中心运维团队,依然从事数据库运维工作。
演讲主题:心的运维– 从大脑说起
内容摘要: 借助DBA的技术背景,尝试以大家容易理解的方式,介绍一种古老的运维理念。以求触动听众,为大家打开一个新的视角。

 


演讲嘉宾:田冰

嘉宾简介: 田冰先生具有十年以上的企业信息化管理实践经验,擅长大型复杂企业级信息战略与架构的设计与创新,对快递和零售行业信息化有较深入的理解。曾历任IBM中 国有限公司系统架构师、项目经理、顾问经理,永辉超市股份有限公司全国信息首席架构师。

演讲主题:大数据技术在传统企业信息化的应用

 


演讲嘉宾:田发明

嘉宾简介: 田发明,就职于CNTV,负责数据库运维相关工作,热衷于大规模数据库运维管理,数据库调优,数据库架构设计。
演讲主题:SQL审核与开发规范
内容摘要: 介绍和探讨在运维Oracle和MySQL期间里遇到的SQL相关方面一些案例、技巧总结,及如何逐步形成适合自身公司相应的开发规范和流程。

 


演讲嘉宾:陈福荣
嘉宾简介: 腾讯互动娱乐事业群高级工程师,先后在上海达梦数据库、腾讯从事研究和开发工作,有将近5年的数据库内核研究和开发经验。目前专注于MySQL的定制和优化工作,开发和维护了腾讯内部的MySQL分支,满足公司游戏业务海量数据管理的功能和性能需求。
演讲主题: MySQL在线加字段实现原理
内容摘要: MySQL直到5.6才支持Online DDL操作,但是加字段等最常见的DDL操作只做到了不锁表的内部拷贝数据。腾讯内部维护了一个MySQL分支(TMySQL),其中一个核心功能就是实现了类似Oracle的不需拷贝数据的快速加字段功能。本次演讲的主要内容就是介绍MySQL在线加字段实现原理,涉及Innodb存储格式、数据字典、redo/undo等方面的基本原理和改造方法。

演讲嘉宾:王斌

嘉宾简介: 王斌,在网易主要从事互联网领域的开源工作,主要维护tcpcopy,gryphon,nginx-hmux-module等开源项目。
演讲主题:MySQL Database Replay
内容摘要: 本次演讲,主要讲述如何从底层来复制MySQL请求到测试服务器中去,从而达到MySQL Replay的目的,进而为MySQL的稳定性测试和性能测试提供有力支持。

演讲嘉宾:卢钧轶

嘉宾简介: 爱捣腾Linux的DBA。现任职于大众点评网DBA团队。四年MySQL DBA经验,一年SA经验。主要关注MySQL、Memcache、MMM等产品的高性能和高可用架构。Weibo:米雪儿侬好的cenalulu

演讲主题:MySQL高可用架构 — MMM在大众点评应用和改进
内容摘要:本次演讲,主要讲述以下几个方面
1. MMM在点评网是如何使用的
2. 细数MMM上踩过的坑以及如何填坑
3. MMM和MHA之间的抉择

演讲嘉宾:李强

嘉宾简介: 李强,现为热璞科技运维架构师,主要从事于运维架构、运维体系建设领域的工作,主要关注网络模拟器、Linux系统、高可用方案等。
演讲主题:运维自动化之运维监控
内容摘要: 运维监控的价值、运维监控的开源解决方案等。

演讲嘉宾:李旭

嘉宾简介: 09年参加工作,曾就职于学大教育,亿美软通等,经历过比较多的数据库产品,包括ORACLE,timesten,MySQL,现就职于网信金融,目前主要专注于MySQL
演讲主题:PACEMAKER+COROSYNC+DRBD+HARPOXY+KEEPALIVED的高可用环境的原理以及应用
内容摘要: 金融行业对数据的一致性要求较高,比较当前主流的高可用架构,选择了DRBD,通过使用COROSYNC来提供集群信息以及状态监测,PACEMAKER负责故障转移以及资源的启动停止和监控,在PRIMARY出现问题的时候,通过PACEMAKER控制VIP迁移来实现高可用,使用HAPROXY实现读写分离,使用KEEPALIVED来避免HAPROXY服务器的单点故障。

演讲嘉宾:K8、刘斐然

嘉宾简介: K8目前就职于先锋金融集团,曾就职于人人网安全中心,任安全经理一职。专注互联网安全很多年。
刘斐然目前就职于先锋金融集团,曾就职于人人网安全中心,浪潮科技,擅长安全工具开发和漏洞研究,写的一手好代码。
演讲主题:P2P行业风险分析与安全防御
内容摘要: 互联网金融作为近年兴起的一个火爆名词,从年初响彻大江南北的余额宝,到后来的百付宝,再到各种P2P贷款,这些新型的互联网金融产品到底有哪些安全隐患呢?到底钱放在P2P贷款里面是否安全?作为投资人,该如何选择?作为网站安全工作者,如何来评估它们的安全性,以及如何提高安全性?

infobright中导入数据避免特殊字符问题

目前在用的是社区版的infobright,不支持DML功能,只能用LOAD DATA方式导入数据。

如果元数据中有特殊控制字符,导入过程中经常会报错,很是恼火。应对策略有两种方法:

  1. 设置Reject File导入之前,设定 @BH_REJECT_FILE_PATH 和 @BH_ABORT_ON_COUNT 就可以忽略多少条导入失败的记录,并且将这些记录保存在指定文件
    /** when the number of rows rejected reaches 10, abort process **/
    
    set @BH_REJECT_FILE_PATH = '/tmp/reject_file';
    
    set @BH_ABORT_ON_COUNT = 10;
    
    BH_ABORT_ON_COUNT 设定为 -1 的话,表示永不忽略。

    也可以设置 BH_ABORT_ON_THRESHOLD 选项,该选项表示有最多多少百分比的数据允许被忽略,因此该选项的值是小数格式,例如 BH_ABORT_ON_THRESHOLD = 0.03(表示3%)

  2. 导出时指定结束符此外,还可以在导出数据时制定结束符,并且设定忽略哪些转义字符(\、”、’ 等字符),例如:
select fields_list... into outfile '/tmp/outfile.csv' fields terminated by '||' ESCAPED BY '\\' lines terminated by '\r\n' from mytable;
  1. 或者,将行间隔符设定为其他特殊标识,例如:select fields_list… into outfile ‘/tmp/outfile.csv’ fields terminated by ‘||’ ESCAPED BY ‘\\’ lines terminated by ‘$$$$$\r\n’ from mytable;当然了,这种情况下,实际数据行中就不能存在 “$$$$$\r\n” 这个值了,否则会被当成换行标识。

MySQL DATE_FORMATE函数内置字符集的坑

今天帮同事处理一个SQL(简化过后的)执行报错:

mysql> select date_format('2013-11-19','Y-m-d') > timediff('2013-11-19', '2013-11-20');                                         

ERROR 1267 (HY000): Illegal mix of collations (utf8_general_ci,COERCIBLE) and (latin1_swedish_ci,NUMERIC) for operation '>'

乍一看挺莫名其妙的,查了下手册,发现有这么一段:

The language used for day and month names and abbreviations is controlled by the value of the lc_time_names system variable (Section 9.7, “MySQL Server Locale Support”).

The DATE_FORMAT() returns a string with a character set and collation given by character_set_connection and collation_connection so that it can return month and weekday names containing non-ASCII characters.

也就是说,DATE_FORMATE() 函数返回的结果是带有字符集/校验集属性的,而 TIMEDIFF() 函数则没有字符集/校验集属性,我们来验证一下:

mysql> set names utf8;
mysql> select charset(date_format('2013-11-19','Y-m-d')), charset(timediff('2013-11-19', '2013-11-20'));
+--------------------------------------------+-----------------------------------------------+
| charset(date_format('2013-11-19','Y-m-d')) | charset(timediff('2013-11-19', '2013-11-20')) |
+--------------------------------------------+-----------------------------------------------+
| utf8                                       | binary                                        |
+--------------------------------------------+-----------------------------------------------+

mysql> set names gb2312;
mysql> select charset(date_format('2013-11-19','Y-m-d')), charset(timediff('2013-11-19', '2013-11-20'));
+--------------------------------------------+-----------------------------------------------+
| charset(date_format('2013-11-19','Y-m-d')) | charset(timediff('2013-11-19', '2013-11-20')) |
+--------------------------------------------+-----------------------------------------------+
| gb2312                                     | binary                                        |
+--------------------------------------------+-----------------------------------------------+

可以看到,随着通过 SET NAMES 修改 character_set_connection、collation_connection  值,DATE_FORMAT() 函数返回结果的字符集也跟着不一样。在这种情况下,想要正常工作,就需要将结果进行一次字符集转换,例如:

mysql> select date_format('2013-11-19','Y-m-d') > convert(timediff('2013-11-19', '2013-11-20') using utf8);
+----------------------------------------------------------------------------------------------+
| date_format('2013-11-19','Y-m-d') > convert(timediff('2013-11-19', '2013-11-20') using utf8) |
+----------------------------------------------------------------------------------------------+
|                                                                                            1 |
+----------------------------------------------------------------------------------------------+

就可以了 :)

P.S,MySQL的版本:5.5.20-55-log Percona Server (GPL), Release rel24.1, Revision 217

MySQL字符集的一个坑

今天帮同事处理一个棘手的事情,问题是这样的:

无论在客户机用哪个版本的mysql客户端连接服务器,发现只要服务器端设置了

character-set-server = utf8

之后,

character_set_client、 character_set_connection、character_set_results

就始终都是和服务器端保持一致了,即便在mysql客户端加上选项

--default-character-set=utf8

也不行,除非连接进去后,再手工执行命令

set names latin1

,才会将client、connection、results的字符集改过来。

经过仔细对比,最终发现让我踩坑的地方是,服务器端设置了另一个选项:

skip-character-set-client-handshake

文档上关于这个选项的解释是这样的:

--character-set-client-handshake

Don't ignore character set information sent by the client. To ignore client information and use the default server character set, use --skip-character-set-client-handshake; this makes MySQL behave like MySQL 4.0

这么看来,其实也是有好处的。比如启用 skip-character-set-client-handshake 选项后,就可以避免客户端程序误操作,使用其他字符集连接进来并写入数据,从而引发乱码问题。

Qihoo360 Atlas MySQL Proxy测试小结

Qihoo360将他们改造后的MySQL Proxy项目开源了,至于为什么起名Atlas就不清楚了,项目地址:https://github.com/Qihoo360/Atlas。我2008年曾测试过官方版本的MySQL Proxy,主要是看中其连接池以及读写分离功能,不过当时的版本效率实在太差,后面就没再关注了。这几天对Qihoo360 Atlas做了下测试,下面是测试结果。

  • 环境准备

服务器端:

测试机 DELL PE R710
CPU E5620  @ 2.40GHz(4 core, 8 threads) * 2
内存 24G
RAID卡 PERC H700 Integrated, 512MB, BBU, 12.10.1-0001
系统 Red Hat Enterprise Linux Server release 6.4 (Santiago)
内核 2.6.32-358.el6.x86_64 #1 SMP
raid级别 raid 5(10K RPM SAS 300G * 6)
文件系统 xfs
硬盘 10K RPM SAS 300G * 6

Proxy代理层端:

测试机 HP DL360 G5
CPU E5405 @ 2.00GHz(4 core, 4 threads) * 2
内存 16G
RAID卡 P400i 256MB, BBU, 4.12
系统 Red Hat Enterprise Linux Server release 6.1 (Santiago)
内核 2.6.32-131.0.15.el6.x86_64 #1 SMP
raid级别 raid 0(10K RPM SAS 146G * 2)
文件系统 ext4
硬盘 10K RPM SAS 146G* 2
  • MySQL及Atlas关键配置
[yejr@imysql.com]# cat /etc/my.cnf

max_connections = 2048
max_connect_errors = 100000

[yejr@imysql.com]# cat /usr/local/mysql-proxy/conf/13306.cnf
event-threads = 16
min-idle-connections = 768
  • 测试方案

1. 采用tpcc-mysql进行压测,但由于Atlas不支持PREPARE,未遂;

2. 采用sysbench进行压测,但由于Atlas当前版本对长连接支持不佳,出现大量的connection lost告警,测试结果几乎无效,忽略;

3. 采用开发者提供的一个简易C程序,进行并发多线程短连接测试,虽然有部分connection lost告警,但比用sysbench时少多了,结果有效;

开发者提供的C程序,若有需要可向开发者提出,由于未得到授权,我不方便将其放上来供下载。

测试模式:

测试程序并发数:32、64、128、192、256、320、384、448、512、576、640,每线程完成10000次请求,每次请求都是随机的SELECT、INSERT、UPDATE,每次UPDATE都是基于主键条件,INSERT就不用说了,SELECT有4种随机模式:

a) /*master*/SELECT * FROM mysqlslap.t1 WHERE /*waht*/id in (N1, N2, N3)

b) SELECT * FROM mysqlslap.t1 WHERE id = N

c) SELECT * FROM mysqlslap.t1 WHERE id in (N1, N2) limit 1

d) /*master*/SELECT * FROM /*test*/ mysqlslap.t1 WHERE id = %d

也就是SELECT请求会模拟强制读MASTER,或者让Atlas自动分配。

  • 测试脚本

测试脚本很简单:

[yejr@imysql.com]# cat Atlas_benchmark.sh

#!/bin/bash

MYSERVER=10.0.0.1
PORT=13306

export LD_LIBRARY_PATH=/usr/local/mysql/lib/mysql

for THREAD in 32 64 128 192 256 320 384 448 512 576 640
do

#记录日志
exec 3>&1 4>&2 1>> check_1m3s_1server_1proxy_${THREAD}_${RANDOM}.log 2>&1

count=1
max=5
#每种并发模式都进行5轮测试,最后取结果平均值
while [ $count -le ${max} ]
do

echo "./check -t short -c ${THREAD} -h ${MYSERVER} -P ${PORT} -u proxy -p proxy -n 10000"
./check -t short -c ${THREAD} -h ${MYSERVER} -P ${PORT}-u proxy -p proxy -n 10000

count=`expr ${count} + 1`

#每次测试完,都会暂停60秒,让数据库歇歇 :)
if [ ${count} -lt ${max} ] ; then
 sleep 60
fi

done

done

测试完后对结果进行整理汇总即可。

  • 测试结果

测试成功次数

Atlas Proxy并发测试成功次数 - 20130911

Atlas Proxy并发测试成功次数 – 20130911

测试成功率

Atlas Proxy并发测试成功率 - 20130911

Atlas Proxy并发测试成功率 – 20130911

  • 结论及建议

Qihoo360开源的精神值得学习,不过目前来看Atlas还有一定提升空间,不妨等它更加稳定并且能支持更多特性后再上线使用不迟。

但是对那些苦于无法将slave从库资源利用起来的同学们来说,在前端加一层Atlas倒是很不错的选择,毕竟其他可选的产品太少了,只要程序中不用到特殊的SQL一般也不会有大问题,注意提高程序对数据的容错性即可。

Nginx HttpMemcModule和直接访问memcached效率对比测试

  • 测试环境:
  1. 测试客户机A: HP DL380G4,2个双核CPU,4G Ram,2块10k RPM SAS盘做raid 1,ext3
  2. Nginx所在服务器B:DELL R710,E5620 * 2,32G Ram,6块盘15K RPM SAS盘做raid 1+0,xfs
  3. Memcached所在服务器C:DELL R710,E5620 * 2,32G Ram,6块盘15K RPM SAS盘做raid 5,ext4
  4. Nginx设置:keepalive 8192
  5. Php fpm设置:listen.backlog = -1
  6. memcached启动参数:memcached -d -m 24576 -p 12000 -c 10240
  7. 内核参数:
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_timestamps = 1

关于这几个内核参数对应的解释可参考资料:2.12. Reduce TCP performance spikes

  • 测试方案:
  1. 使用php连接本地nginx代理,存取远程memcached数据;
  2. 使用php直接连接远程memcached服务器;
  3. 从测试客户端用ab发起并发测试;
  4. 并发线程从64开始,直到2048,分别是64的N倍;
  5. 每种并发模式都进行5轮测试,最后取平均值;
  6. 存储在memcached中的key长度96个字符,value长度400字符,总是随机生成;
  • 测试结果:

NginxHttpMemcMC-vs-NativeMC-benchmark-2013091301  NginxHttpMemcMC-vs-NativeMC-benchmark-2013091302

NginxHttpMemcMC-vs-NativeMC-benchmark-2013091303  NginxHttpMemcMC-vs-NativeMC-benchmark-2013091304

结论及建议:

  1. Php程序通过HttpMemcMC访问memcache和直接访问memcached的效率并没有太多损失;
  2. 采用php直接访问memcached,失败的次数相比通过HttpMemcMC有较大增加,应该是HttpMemcMC在keepalive方面更有优势;
  3. 后续会在进行一次测试,调整nginx、php及内核相关参数,再做对比;
  4. 本次测试没有和正常的http请求混在一起对比,测试结果不具备绝对参考价值;

单从本次测试结果来看,HttpMemcMC值得拥有 :)

  • 结果结果更新:

调整上述几个内核参数:

net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_timestamps = 1

通过调整内核参数,调整tcp连接复用性提高tcp效率,新的测试结果如下:

NginxHttpMemcMC-vs-NativeMC-benchmark-2013091305   NginxHttpMemcMC-vs-NativeMC-benchmark-2013091306 NginxHttpMemcMC-vs-NativeMC-benchmark-2013091307   NginxHttpMemcMC-vs-NativeMC-benchmark-2013091308

备注:由于2次测试案例中,每并发线程请求数不一样,所以你会发现两边的数据无法直接对比,这是我的失误,抱歉。

  • 补充小结:

调整完内核后:
1. 可以发现,HttpMemc的平均效率只有NativeMC 72.62%;
2. 调整内核tcp参数对提升tcp效率非常有帮助,Failed requests次数完全为0;
3. 由于可以提高memcached连接复用率以及对程序透明的好处,即便HttpMemc性能不如NativeMC,损失并不是非常厉害,仍然是可以接受的;

[MySQL FAQ]系列 — 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.

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