Archive for 十月 2015

MySQL binlog相关源码浅析

今天整理了一些MySQL binlog相关的原理,代码结构和源码函数调用,不敢藏私。

整理的内容主要针对以下四个问题:

  1. binlog文件的逻辑、物理表现形式
  2. slave io到底是怎么连上Master的
  3. sql线程是怎么读取二进制信息,应用到本地MySQL的
  4. binlog_format=ROW格式下,MySQL是怎么用二进制保存一行数据中不同数据类型的

一、binlog文件和文件的逻辑、物理表现形式

1. binlog文件

binlog文件主要包括:

  1. mysql-bin.000001
  2. mysql-bin.index

其中:

mysql-bin.index内保存着server中未purge的binlog文件,以“文本”形式保留的。

mysql-bin.index的内容示例:

mysql-bin.000001是真正的binlog文件,它是以“二进制”形式存在,对它的读必须使用特殊的工具(mysqlbinlog)才能以人能看得懂的方式打印出来。

2.binlog文件格式

mysql-bin.index没啥可说的,我们专门看一下二进制binlog文件。

binlog文件格式有以下特点:

  1. binlog是由event组成,event是binlog的逻辑最小单元。
  2. 文件头的头四个字节为BINLOG_MAGIC(fe 62 69 6e)
  3. 紧接着这四个字节的是 descriptor event : FORMAT_DESCRIPTION_EVENT
  4. 文件的末尾是 log-rotation event: ROTATE_EVENT
  5. 这两个event中间是各种不同的event,每个event代表Master上不同的操作。

下面对基本比较关键的概念进行说明:

  • BINLOG_MAGIC

利用hexdump -C 读取mysql-bin.000005的内容,

这里分别以十六进制和ASCII码展示显示,我们可以看到binlog的头四个字节是固定的:fe 62 69 6e,后三个字符ASCII码为bin,指明展示一个binlog文件。这四个字节成为 BINLOG_MAGIC。

  • event

mysqlbinlog -vvv 读取mysql-bin.000011的内容示例:

这里可以看到,第一个event是FORMAT_DESCRIPTION_EVENT,它记录了这个binlog的版本(MySQL 5.0以后binlog 的版本都是4)。最后一个event,是ROTATE_EVENT,它记录了切换到下一个binlog文件的文件名。

在它们两个之间是各种其他的event,目前的event类型有:

当然,内部已经有部分event被弃用了,我们不一一列举,这里只简单介绍几个平时经常见到的:

  • QUERY_EVENT :用于具体的SQL文本。如果binlog_format=statement方式下,insert,update,delete等各种SQL都是以Query event记录下来的。
  • WRITE_ROWS_EVENT,UPDATE_ROWS_EVENT,DELETE_ROWS_EVENT : 在binlog_format=row方式下,insert,update,delete操作的行信息分别以这三种event记录下来。
  • GTID_LOG_EVENT:5.6的GTID模式下,每个事务的GTID序号被记录到这种EVENT中。
  • PREVIOUS_GTIDS_LOG_EVENT :5.6的GTID模式下,这个event记录了生成这个binlog之前,MySQL已经执行的所有事务的GTID集合

二、slave io在源码中是怎么连上Master的

这里主要描述源码中的函数调用关系

1. slave如何注册并请求master 的binlog

slave io线程对应的入口函数为sql/rpl_slave.cc:handle_slave_io()

该函数核心主要是做了以下三个事情:

  1. safe_connect(thd, mysql, mi)
  2. register_slave_on_master(mysql, mi, &suppress_warnings)
  3. request_dump(thd, mysql, mi, &suppress_warnings)
  4. event_len= read_event(mysql, mi, &suppress_warnings);

也就是说,它先以标准的连接方式连上master MySQL,然后把自己注册到master上去,接着调用request_dump向master请求binlog数据,最后一个一个event读取并存放到本地relay log中。

  • safe_connect

连接MySQL的标准方式,MySQL c的connector也是用这种方式连接MySQL server的。

  • register_slave_on_master

register_slave_on_master核心的代码为

这里,slave把自己的slave_id,IP,端口,用户名提交给Master,用于注册自己到Master上去。

  • request_dump

request_dump的核心代码如下:

这里会根据GTID来进行判断,如果是GTID模式,那么把本地执行的GTID集合及其他相关信息传给master;如果不是GTID模式,那么就把master log file和Pos传给主库。主库如何根据这些信息来发送binlog的event,参考下节。

  • read_event

read_event调用了cli_safe_read(),cli_safe_read()调用了my_net_read(),等待主库将binlog数据发过来

也就是说,read_event被动的从网络中接受主库发过来的信息。

2. master 如何处理slave的 binlog 请求

MySQL处理各种命令的核心函数为:sql/sql_parse.cc:dispatch_command

该函数的核心代码如下:

该函数会根据用户的请求来确定做什么事情,

  • COM_REGISTER_SLAVE则调用register_slave(thd, (uchar*)packet, packet_length)注册slave
  • COM_BINLOG_DUMP_GTID 则调用com_binlog_dump_gtid(thd, packet, packet_length);
  • COM_BINLOG_DUMP 则调用com_binlog_dump(thd, packet, packet_length);

我们这里以com_binlog_dump为例介绍master怎么发送binlog event给slave的。

com_binlog_dump核心代码为:

  1. kill_zombie_dump_threads(&slave_uuid);
  2. mysql_binlog_send(thd, thd->strdup(packet + 10), (my_off_t) pos, NULL)

kill_zombie_dump_threads()函数:如果新的server_id相同的slave注册上来,master会移除跟该slave的server_id匹配的的binlog dump线程

com_binlog_dump()会调用mysql_binlog_send()来打开文件,将文件指针挪到指定位置,读取文件,将一个个的event按照事件顺序发给slave。

综上

MySQL复制需要slave先注册到Master,再向Master提交binlog和POS,请求发送binlog。Master接收到请求后,先做一系列验证,打开本地binlog文件,按照内部event的顺序,依序发给slave。

三、sql线程在源码中是怎么读取二进制信息,应用到本地MySQL的

sql线程在5.6引入了db级别的并行,所以有两个入口

handle_slave_worker线程是主要干活的函数,handle_salve_sql函数作为协调器会启动和分配worker线程。

handle_slave_sql函数主要调用了slave_worker_exec_job。

slave_worker_exec_job的主要功能:

  1. job_item= pop_jobs_item(worker, job_item); ev= static_cast<Log_event*>(job_item->data);
  2. error= ev->do_apply_event_worker(worker);

该函数做到事情其实就是 从handle_salve_sql()获得具体的event(ev),然后调用ev->do_apply_event_worker(worker),利用c++的多态特性,调用真正的event的do_apply_event虚函数,以便将不同的event的操作在本地做一遍。

这里需要大家回顾一下event的概念了,event是binlog的最小单元,所有的event的父类是Log_event(抽象基类),它定义了一系列虚函数,其中就包括我们这里调用的函数:

这里举一个insert语句对应的的Write_rows_log_event例子,简单说明一下数据是怎么应用到本地MySQL的。

Write_rows_log_event,Update_rows_log_event和Delete_rows_log_event的do_apply_event都是调用的它的基类Rows_log_event的do_apply_event。

Rows_log_event的do_apply_event主要功能如下:

  1. m_table= const_cast <relay_log_info* style=”-webkit-print-color-adjust: exact;”> (rli)->m_table_map.get_table(m_table_id);
  2. error= (this->*do_apply_row_ptr)(rli);

get_table()先从table map中获得对应的table的信息,然后调用do_apply_row_ptr函数指针指向的函数来将event对应操作应用到本地MySQL。

do_apply_row_ptr函数指针可能指向以下几种不同的函数:

  • do_hash_scan_and_update
  • do_index_scan_and_update
  • do_table_scan_and_update
  • do_apply_row

Write_rows_log_event是insert,不用查找数据,所以它调用的是do_apply_row。

do_apply_row主要的功能就是调用了do_exec_row ….汗

do_exec_row是Write_rows_log_event自己实现的,它的主要功能是调用了 write_row ….汗

write_row也是Write_rows_log_event自己实现的,它的主要功能是:m_table->file->ha_start_bulk_insert(estimated_rows);也就是说,它直接把这一行数据交给了存储引擎,让存储引擎把数据给插进去。

四、binlog_format=ROW 格式下,MySQL是怎么用二进制保存各种不同的数据类型的

在sql/log_event.cc:log_event_print_value()函数中详细描述了MySQL的各种数据类型的二进制表现形式,摘录如下:

这里有几个比较有意思的地方:

  1. MYSQL_TYPE_STRING 类型,它的length占用的字节数是不固定的。如果string长度不到大于255,则需要占用2个字节,所以,MySQL在定义String类型的字段时,255是一个坎,如果字段不可能超过255个字节,不建议定义长度的时候超过255,否则MySQL存储数据时会白白浪费一个字节。
  2. MYSQL_TYPE_DATETIME类型。它存储的格式就是把年-月-日 时:分:秒按顺序存储下来的,比如:2015-10-10 22:45:55存储下来就存储为20151010224545。这种存储格式比较浪费,所以字节数相比timestamp占用的也比较多。