由于线上主流MySQL数据库用的MySQL-5.1.48版本，这个版本运行近两年来，暴露的问题比较少，也是相对比较稳定的一个GA版本。最近研究升级到MySQL-5.1.x系列，发现没有找到能说服我自己的理由，除非是遇到了真的过不去的坎，或者特别想利用新的特性，因为从sysbench测性能试的结果看，不分伯仲。 mysql-5.1.48 mysql-5.1.56 OPR requests latency requests latency select 37331.96 37192.82 0.85 0.86 37396.46 37399.82 0.85 0.85 update-key 17305.59 17207.60 1.85 1.86 16855.06 16633.32 1.89 1.92 update-nokey 15517.05 15600.70 2.06 2.05 15258.13 14713.75 2.09 2.17 insert 9807.19 9892.62 3.26 3.23 11030.71 8748.67 2.90 3.65 delete 21095.04 21721.00 1.51 1.47 19690.32 22372.53 1.62 1.43 trx 19112.93 [...]

背景： 1. 库升级时，监测最近有哪些活跃用户访问此库 2. 某些场合下需要记录用户的对库表的修改 3. 需要对用户的特殊行为事后监控，出问题可查 4. 对需求3的实行监测控制，杜绝非规则之内SQL行为   解决方案： 1. init_connect属性 目前线上运行的主流版本  MySQL-5.1.48在安全审计方面支持性较差，而在MySQL-5.5版本中得到很好改善。在老版本中有个init_connect属性，在用户连接时执行init_connect的内容。为支持用户行为监控，在init_connect内赋值MySQL内部API获取的值，典型的是IP/USER，自动地写入到临时表中。优点就是方便，即配即用，缺点是很难监测到用户干了些什么。   这个属性粒度太粗，线上应用于白名单监测。   2. binlog扩展 在MySQL-5.1.48中扩展binlog是init_connect的升级版，即在binlog中记录用户的行为。大家可能会想，为何不把slow_query设置到毫秒级，让slow_query记录详细信息。抛弃这种想法的理由是，slow_query会记录大量的信息，耗IO和DISK，完全没有必要。扩展binlog的思想很简单，就是修改binlog的存储协议格式，在头部加入IP/USER，额外空间是4+6（IP+USER)，对性能没有影响。不幸的是，目前binlog的协议头早已被用完，扩展性大大打折扣。修改后意味着生成的binlog不能被别的按原生态MySQL binlog协议解析的MySQL或工具所读取，修改后的MySQL不能读取之前生成的MySQL binlog。   binlog扩展应SQA环境下的部分业务。   3. audit_plugin 在MySQL-5.5版本中，插件得到很好的支持，灵活的动态加载、卸载审计插件。API中可以得到THD指针，权利变得可以无限想象。如何做到对用户配置的规则灵活的支持，才是可用性的关键。   1)  用户规则静态配置 典型的用户对库表的操作DDL，或是无条件的DELETE。 另外，基于安全方面需求的各种意想不到的的规则加入，例如SQL注入的预防。   为此基于my.cnf中加入audit栏支持用户初始化的配置，在MySQL启动时读取。   2)  用户规则的动态可配 用户的规则设置必须支持动态可配，可以有两种方法： * 通过扩展变量来设置，例如set rule=”add|del $rule”。 这样做的坏处就是必须重在MySQL层hook部分代码新解析对应的handler * 通过修改my.cnf中audit栏，每次动态的读取，更新内存中历史规则。 每次判断文件修改时间，与上次读取时保存的时间不一样则读取。   3)  审计handler 审计插件被触发时产生的事件(mysql_event_general)中记录了与SQL相关的非常丰富的信息，事件被传递到audit插件的notify函数参数中： static void audit_null_notify(MYSQL_THD [...]