如果你想参与淘宝MySQL分布式集群的设计，为开发人员提供高质量的MySQL数据存储服务支持，学习MySQL诊断问题的方法，欢迎加入淘宝产品DBA北京团队，请投递简历给我：danchen#taobao.com (将#换成@)

看看Oracle对MySQL的规划，你会更倾向MySQL-5.5。但对于仍然使用MySQL-5.1.48的应用，必须要关注当前版本存在哪些问题。

下面是所列的几大主要版本修复的我们所关心的BUG，如有遗漏，后续补充。

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-49.html

暂无

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-50.html

#45012 my_like_range_cp932 generates invalid string （编码集，可以忽略）

#54117 crash in thr_multi_unlock, temporary table (debug版本存在)

#54465 assert: field_types == 0 || field_types[field_pos] == MYSQL_TYPE_LONGLONG(testcase好几个，但一直没有遇到)

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-52.html

暂无

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-52sp1.html

新特性innodb_use_sys_malloc=0|1

http://dev.mysql.com/doc/innodb-plugin/1.0/en/innodb-performance-use_sys_malloc.html

#55421 Protocol::end_statement(): Assertion `0′ on multi-table UPDATE IGNORE （trigger执行时有活跃的select时会触发）

#55779 select does not work properly in mysql server Version “5.1.42 SUSE MySQL RPM”(当时间不是‘YYYY-MM-DD HH:MM:SS’格式时候，存在 >=只会查>的结果)

#50402 Optimizer producing wrong results when using Index Merge on InnoDB（join时可能存在，由于innodb在做index merge时逻辑错误导致）

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-53.html (FIXED TOO MANY BUGS IN REPLICATION)

#56982 Assertion Failure from ha_innobase::innobase_peek_autoinc() when auto_inc > 0 （alter table宕机后show create table OR information必然触发，当然前提是alter table后要宕机）

#55478 Row events wrongly apply on the temporary table of the same name (RBR要注意了)

#55375 Transaction bigger than max_binlog_cache_size crashes slave（仅仅在备库可能出现，因为备库的IO线程rollback所有事务，而不能仅仅rollback当前的stmt）

#55263 assert in check_binlog_magic (通过change master to改变relay log的信息时触发，因为没有清空IO_CACHE中内容导致读陈旧的数据)

#38718 slave sql thread crashes when reading relay log （invalid类型的binlog event导致备库crash）

#56423 Different count with SELECT and CREATE SELECT queries (create table … select要小心了)

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-54.html

几个不怎么关系的编译问题(Bug #57992, Bug #57993, Bug #57994, Bug #57995, Bug #57996, Bug #57997, Bug #58057)

#56228 The server could crash with an assertion error, if a stored procedure, stored function, or trigger modified one InnoDB table containing an auto-increment column, and dropped another InnoDB table containing an auto-increment column（修改autoinc列的DDL还是可能出现，做DDL的不要drop另外一个含autoinc的表）

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-55.html (seems good)

#18274 InnoDB auto_increment field reset on OPTIMIZE TABLE（optimize table要注意了,平常偶尔会用到）

#57288 binlog_tmp_table fails sporadically: “Failed to write the DROP statement …” （临时表关闭可能导致binlog错误，还没有遇到过）

http://dev.mysql.com/doc/refman/5.1/en/news-5-1-56.html

#59308 Incorrect result for SELECT DISTINCT <col>… ORDER BY <col> DESC （线上还没有怎么注意到这个问题，重视下）

#59338 Inconsistency in binlog for statements that don’t change any rows STATEMENT SBR （对InnoDB来说，虽然binlog可能不一致，但对数据没有影响）

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 thd,  unsigned int event_class, const void *event)

我们可以对event类型进行强制转换为mysql_event_genereal:

if (event_class == MYSQL_AUDIT_GENERAL_CLASS) {
pEvent = (const struct mysql_event_general *) event;

在头文件plugin_audit.h中，定义了该事件类型的结构体：

struct mysql_event_general
{
unsigned int event_subclass;
int general_error_code;
unsigned long general_thread_id;
const char *general_user;
unsigned int general_user_length;
const char *general_command;
unsigned int general_command_length;
const char *general_query;
unsigned int general_query_length;
struct charset_info_st *general_charset;
unsigned long long general_time;
unsigned long long general_rows;
};

从结构体中，我们可以看出事件中记录了包括用户名，线程id，执行的sql等信息，另外结合THD，还可以得到用户的主机名以及操作的数据库名，这些信息足以满足我们审计的需求。

对规则应用时重点是如何对众多的规则进行判断，即要考虑性能。目前的优化留给用户处理，即在配置文件中将粒度粗的，出现概率大的写在前。

扩展后的audit插件目前主要应用于安全需求方面。

通过安全审计，做到事前监测触发，防患于未然。

MySQL无法连接，pstack 无法打印出MySQL的stack trace。在alert.log里仅有一条error：

110829 20:25:51 [ERROR] mysqld: Got error 514 from select

这条语句出现在监测到问题之前发生（精确的时间点我这没有拿到）。

查了下是select系统调用的一个bug。有这么一句解释：此错误是用户程序不应该看到的， 不幸被MySQL看到了：
errno 514 is ERESTARTNOHAND (restart if no handler), and is in a section marked as “should never be seen by user programs”.

对于的OS和MySQL版本信息如下：

$ uname -a
Linux dev031033.sqa.cm4 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
$ mysql –version
mysql Ver 14.14 Distrib 5.1.37, for unknown-linux-gnu (x86_64) using EditLine wrapper

那只能很不幸的说，在2.6.9版本中确实有这么一个bug，但这个bug在2.6.38中已经进行了处理，将ERESTARTNOHAND替换成EINTR：

fs/select.c: poll_select_copy_remaining：
    if (ret == -ERESTARTNOHAND)
        ret = -EINTR;

在此情况下，升级OS是一种方案，但周期较大，另外一种可行方案就是修复MySQL调用select之处的异常处理。

在MySQL中，有两处会使用select，除了监听网络连接使用select外，使用更多的是做sleep之用。

对于用作sleep功能的select，比较典型的用法，利用timeout机制来实现sleep，代码如下：

void
os_thread_sleep(
/*============*/
    ulint   tm) /* in: time in microseconds */
{
#ifdef __WIN__
    Sleep((DWORD) tm / 1000);
#elif defined(__NETWARE__)
    delay(tm / 1000);
#else
    struct timeval  t;

    t.tv_sec = tm / 1000000;
    t.tv_usec = tm % 1000000;

    select(0, NULL, NULL, NULL, &t);
#endif
}

但这个返回值不影响程序的正常运行。

这里插个题外话，select和nanosleep，哪个更适合做sleep之用。
对比usleep，nanosleep有线程安全、能接受信号量、可以大于1s的sleep等优势，虽然2.6已经解决了在2.4都存在SIGSTOP/STICONT导致stop时间不计的精确的问题，但还是存在可能最多1/HZ s的误差。那么，select是否也有此现象？答案是肯定有。两者都是基于ktime_t数据结构的内核定时器机制，均面临着实现上的精度问题：最坏情况下1/HZs，2.4之前是HZ是100，而后2.6设为1000，即精度改为1ms。替代select的nanosleep的代码为：

while(nanosleep(&req,&req)==-1 && errno == EINTR)

      continue;

回到主题，另外一个可能出问题的就是select的本职工作：

5050   while (!abort_loop)
5051   {
5052     readFDs=clientFDs;
5053 #ifdef HPUX10
5054     if (select(max_used_connection,(int*) &readFDs,0,0,0) < 0)
5055       continue;
5056 #else
5057     if (select((int) max_used_connection,&readFDs,0,0,0) < 0)
5058     {
5059       if (socket_errno != SOCKET_EINTR)
5060       {
5061     if (!select_errors++ && !abort_loop)    /* purecov: inspected */
5062       sql_print_error("mysqld: Got error %d from select",socket_errno); /* purecov: inspected */
5063       }
5064       MAYBE_BROKEN_SYSCALL
5065       continue;
5066     }
5067 #endif  /* HPUX10 */

从 log看遇到一次514错误代码，但从监听网络连接逻辑看，新连接不能成功，说明select没有监听到读事件，即readFDs可能已经出问题。那么，这个问题说到底，还是select问题，之前线上遇到在超过1024的FD时候出错，在后续版本提供poll来取代select。当然，不用epoll又是另外一个话题。

到此，514错误代码，给了我们使用WITH_POLL编译使用poll的另外一个理由。

本文的目的是为了展示如何从row模式事件中解析数据，因此事件中一些记录其他信息的字节会直接略过，感兴趣的同学可以看看log_event.h以及log_event.cc两个文件。

获取Binlog事件：

Mysql对Binlog的处理是以事件为单位的，每一次DML操作可能会产生多次事件，例如对于innodb存储引擎，会额外产生一条QUERY_EVENT（事务的begin语句）以及XID_EVENT(事务提交)。

通过调用libmysql.so库中的cli_safe_read()函数可以获取一次binlog事件：

cli_safe_read(mm);   // mm类型为MYSQL*

net =  &mm->net;

buf = (const char*) net->read_pos + 1;

Binlog的事件类型大约有27种，这里只介绍与ROW模式相关的事件

1)       QUERY_EVENT：与STATEMENT模式处理相同，存储的是SQL，主要是一些与数据无关的操作，eg: begin、drop table；

2)       TABLE_MAP_EVENT：记录了下一条事件所对应的表信息，在其中存储了数据库名和表名；

3)       WRITE_ROWS_EVENT：操作类型为insert；

4)       UPDATE_ROWS_EVENT：操作类型为update；

5)       DELETE_ROWS_EVENT：操作类型为delete；

6)       XID_EVENT， 用于标识事务提交。

在buf[EVENT_TYPE_OFFSET]中记录了事件的类型 (EVENT_TYPE_OFFSET = 4)，根据其中记录的整数，对比log_event.h中的Log_event_type，可以找到相应的事件类型。

以一条insert语句为例，包含4个事件：

TABLE_MAP_EVENT

QUERY_EVENT  (begin)

WRITE_ROWS_EVENT

XID_EVENT

事件时间戳：

buf[0] ~ buf[3]的四个字节，存储了执行操作前的时间戳。

事件长度：

Buf[9]开始的四个字节构成的整数，可以使用如下的方式来进行整数转换：

#define UCHAR(ptr) ((*(ptr)+256)%256)

const char *ptr = buf + 9;

unsigned int data_len = UCHAR(ptr) + (UCHAR(ptr+1)<<8) + (UCHAR(ptr+2)<<16)  + (UCHAR(ptr+3)<<24);

获取数据库和表名：

由于在insert/delete/update事件中不记录表的相关信息，因此每次DML操作都会产生一个TABLE_MAP_EVENT事件，其中存储了获取数据库名和表名。

例如对于数据库名：tt0001；表名：x18，从buf[27]开始表示为如下格式：

解析数据：

在buf中记录了很多信息，但我们的目的是为了解析出数据，因此可以跳过一些字节，直接到达我们的目标数据头部。

cols = buf[27]; //在insert/delete/update事件中,buf[27]表示列的个数

bits = (cols+7)/8

对于WRITE_ROWS_EVENT、DELETE_ROWS_EVENT： ptr  =  buf +28+bits

对于UPDATE_ROWS_EVENT：ptr  =  buf +28+bits * 2

从ptr开始，记录了我们需要解析的数据。

1)       UPDATE_ROWS_EVENT

每更新了多少行，就有多少对 old/new record，当一个事件包存储不下所有记录时，将会拆分成多个 UPDATE_ROWS_EVENT事件。

2)  WRITE_ROWS_EVENT

包含一条插入的数据record

3)  DELETE_ROWS_EVENT

包含被删除的数据record，格式为：

从上面的分析可以看出，要想从binlog中解析出数据，除了辅助信息外，关键是要从record中获取得到行数据，因为DML操作对应的事件类型，都以record为记录单位。

Record结构：

在Record的前几位，会用多个字节来表示值为NULL的列，record的结构可表示为

其中bit_map的所占字节数为(cols+7)/8

例如，执行：insert into xx values(1, NULL, NULL, 15, “ssss”);

xx表有5列，需要(cols +7)/8 = 1 个字节就可以表示所有的列

bit_map = 230，230转换为二进制:1110 0110

其中，最低位表示第一列，第cols( = 5)位为最后一列，为1表示该列值为NULL，为0表示非NULL，在随后的数据记录中只会记录非NULL的值，例如这里跳过bit_map所占字节之后，只会记录1、15和‘ssss’

再比如，当执行如下语句时：insert into x14(a,b) values (NULL,”dsda”);

这里有9列，因此需要2个字节记：

ptr[0] = -4； ptr[1] = -1

转换为二进制  (ptr[1]）1111 1111  (ptr[0])1111 1100

注意，这里虽然在SQL语句中a值为NULL，但由于a列是自增类型，因此存储在binlog中的就是一个整数，而非NULL值.

对于值为NULL的列，我们可以通过表的定义得到该列的默认值。

解析不同的数据类型：

在record中bit_map之后的列数据中，针对不同的数据类型，可能在record中占用不同的字节，因此需要针对每种数据类型进行处理，为了获取到每一列的信息，我们可以调用MYSQL的接口函数mysql_fetch_field()。这里需要注意一种特殊情形，即对于set和enum类型，在调用该API时，会被转换为MYSQL_TYPE_STRING类型，可以调用show columns from 来得到这两种类型的定义。

这里列出了大部分常用数据类型的字节数和解析方法：

1. MYSQL_TYPE_LONG

Int类型，占用4个字节，sint4korr(ptr)

2.  MYSQL_TYPE_TINY

Tinyint类型 ，占用1个字节

3. MYSQL_TYPE_SHORT

smallint 类型， 2个字节, sint2korr(ptr)

4. MYSQL_TYPE_INT24

MEDIUMINT类型，3个字节, sint3korr(ptr)

5. MYSQL_TYPE_LONGLONG

Bigint 类型，8个字节, sint8korr(ptr)

6. MYSQL_TYPE_NEWDECIMAL

Decimal类型，精度限制为65， 字节数与该类型的定义相关，可以参考用户手册 ，对该类型的解析主要是计算出其占用的字节数，调用libmysql.so库中的bin2decimal函数来实现解析。

7. MYSQL_TYPE_FLOAT、MYSQL_TYPE_DOUBLE

直接进行类型的强制转换，分别占4和8个字节，然后根据定义对输出进行精度控制。

8. MYSQL_TYPE_BIT

Bit类型，占用的字节数与其定义相关，计算方式：

byt_len = length%8==0? length/8 : (length/8 + 1);

例如，当定义为bit(M)时，length = M;将byt_len个字节中存储的数据转换为一个整数。

9.  MYSQL_TYPE_SET

SET类型，定义为SET(M)，M值为以下范围时：

1 ~8，1个字节

9~16，  2个字节

17~24， 3个字节

25~32， 4个字节

33~64， 8个字节

然后将相应字节内的数转换为整数即可

10.  MYSQL_TYPE_ENUM

Enum类型，当该类型内的元素超过255个时，使用2个字节，否则使用1个字节表示，相应字节内转换为整数M，表示在enum中的第M个元素。

11.  MYSQL_TYPE_STRING、MYSQL_TYPE_VAR_STRING、MYSQL_TYPE_BLOB

包括char()、varchar()以及text类型，其处理方式相同，在record中首先根据其定义的长度，例如:

对于varchar(10)，使用一个字节记录长度；而对于varchar(300)，则需要使用两个字节来记录字符串的长度；

字符串“abcdef”，在record中被记录为“6abcdef”。

12. MYSQL_TYPE_TIME

Time类型，3个字节，计算方法：

d_int = UCHAR(ptr) + (UCHAR(ptr+1)<<8) + (UCHAR(ptr+2)<<16);

例如对于‘12:01:22’，计算结果为120122

13. MYSQL_TYPE_TIMESTAMP

timestamp时间戳类型，4个字节，直接进行类型的强制转换为整数

14. MYSQL_TYPE_DATE

Date类型，3个字节，计算方法：

d_int = UCHAR(ptr) + (UCHAR(ptr+1)<<8) + (UCHAR(ptr+2)<<16)

例如：

00001111     10110111    00100001

其中，1-5位表示日期，6-9位表示月份，剩余的表示年份，因此上述date类型可转换为2011-09-01

15. MYSQL_TYPE_YEAR

Year类型，1个字节，记录年份，用一个字节记录，从1900年开始

例如，当值为112时，表示112+1900 = 2012年

16. MYSQL_TYPE_DATETIME

Datetime类型，8个字节，直接类型转换为long long，

例如对于 2011-08-27 19：32：46

计算结果值为20110827193246

其实，不管是什么数据类型，我们只要知道其占有的字节数，就能推敲出他们在文件中存储的格式。

未来可能的应用

1. 通过解析binlog中的行数据，进行增量数据dump；

2. 结合handlersocket进行replication。

产品DBA

1、熟悉MySQL数据库体系结构与性能优化
2、熟悉关系数据库原理与设计，有大型项目的数据库设计和支持经验优先
3、精通SQL调优
4、熟悉unix/linux操作系统的使用
5、熟悉shell&perl编程
6、大学本科以上，计算机相关专业

我们更希望你具有如下的能力或潜质：
1、良好的C，C++或者java编程能力
2、了解分布式Cache,或者一些NoSQL产品的源代码
3、对Hadoop大数据量计算，或者对HBase在线应用有一些尝试，或者对这方面感兴趣

如果你具有如下的能力，我们将更加欢迎：
1、良好的产品领悟能力，以及系统架构，分析能力
2、恰当合理的利用各种技术，解决业务系统瓶颈，以及未来发展问题

在淘宝，可以接触大量实际的业务需求，海量数据，高并发，每天都在面对挑战，至身这样的环境，你每天不得不去思考，每天去解决各种各样的问题，如果自己长时间解决不了，你可以寻求淘宝牛人的帮助。开放，相互帮助是淘宝的氛围。这是一条快速成长的捷径，快点加入我们吧。 简历请发送至 danchen(#)taobao.com ，将(#)换成@

View Larger Map

更多信息，请参考淘宝技术嘉年华官方

用户体验看起来比较友好的数据同步方法有：
1、全量dump某个时间点之前的数据，并记录期间的增量日志A
2、apply日志A内的数据，并记录期间的增量日志B
3、apply日志B内的数据，并记录期间的增量日志C
4、不断重复第3步，直到日志C足够小
5、将整个前台系统变为只读，apply日志C内的数据
6、将前台系统切换到Hbase上，并打开更新
该方案实现比较复杂，迭代日志的做法看起来没完没了，而且容易引起少部分用户数据不一致。但是只读的时间非常短，大部分用户都能在数据同步期间自由使用应用。

简单概括一下：
方案1：所有用户都会受到长时间的小影响（只读）
方案2：少部分用户会受到短时间的大影响（数据不一致）

问题：
是不是牺牲小部分人来成全大部分人就是对的？
在这个问题上，德先生（democracy）是不是最终答案？

这个问题我没有想到答案，
但是针对迭代日志是不是没完没了的疑问，阿基里斯悖论给了我一点线索：
阿基里斯是一个跑得很快的神话人物，芝诺提出“假如乌龟领先阿基里斯1000米，则阿基里斯永远不可能追上乌龟”。这个结论的推理过程是这样的：
1、乌龟领先阿基里斯1000米
2、阿基里斯追了1000米
3、乌龟前进了100米（假设乌龟速度是阿基里斯的十分之一）
4、阿基里斯追了100米
5、乌龟前进了10米
。。。
6、阿基里斯追了n米
7、乌龟前进了n/10米
。。。
8、阿基里斯无限逼近乌龟，但是永远不可能追上

阿基里斯真的追不上乌龟？当然不可能：
1000*(1+0.1+0.01+…)=1000*(1+1/9)=10000/9
在10000/9米处，阿基里斯就会和乌龟并驾齐驱，然后超越。

回到增量日志迭代同步的问题。我们在什么前提下，可以认为迭代可终止：
1、日志apply无停顿（阿基里斯一直在跑）
如果apply完一段日志，不是马上去aply新产生的增量日志，那么迭代很可能无法终止
2、日志apply速度大于增量日志生成速度（阿基里斯要跑得比乌龟快）
这个比较显而易见。如果不是这样，日志只会越积越多，不可能apply完成

这是我的一些看法。在不影响用户的前提下，希望以后能够实现完美的数据迁移，呵呵。