共计 5575 个字符，预计需要花费 14 分钟才能阅读完成。
这篇文章将为大家详细讲解有关 MySQL 中 binlog 有什么用，丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
一、binlog 文件和文件的逻辑、物理表现形式
1. binlog 文件
binlog 文件主要包括：
mysql-bin.000001
mysql-bin.index
其中：
mysql-bin.index 内保存着 server 中未 purge 的 binlog 文件，以“文本”形式保留的。
2.binlog 文件格式
mysql-bin.index 没啥可说的，我们专门看一下二进制 binlog 文件。
binlog 文件格式有以下特点：
binlog 是由 event 组成，event 是 binlog 的逻辑最小单元。
文件头的头四个字节为 BINLOG_MAGIC（fe 62 69 6e）
紧接着这四个字节的是 descriptor event：FORMAT_DESCRIPTION_EVENT
文件的末尾是 log-rotation event: ROTATE_EVENT
这两个 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 类型有：
enum Log_event_type {
UNKNOWN_EVENT= 0,
START_EVENT_V3= 1,
QUERY_EVENT= 2,
STOP_EVENT= 3,
ROTATE_EVENT= 4,
INTVAR_EVENT= 5,
LOAD_EVENT= 6,
SLAVE_EVENT= 7,
CREATE_FILE_EVENT= 8,
APPEND_BLOCK_EVENT= 9,
EXEC_LOAD_EVENT= 10,
DELETE_FILE_EVENT= 11,
NEW_LOAD_EVENT= 12,
RAND_EVENT= 13,
USER_VAR_EVENT= 14,
FORMAT_DESCRIPTION_EVENT= 15,
XID_EVENT= 16,
BEGIN_LOAD_QUERY_EVENT= 17,
EXECUTE_LOAD_QUERY_EVENT= 18,
TABLE_MAP_EVENT = 19,
PRE_GA_WRITE_ROWS_EVENT = 20,
PRE_GA_UPDATE_ROWS_EVENT = 21,
PRE_GA_DELETE_ROWS_EVENT = 22,
WRITE_ROWS_EVENT = 23,
UPDATE_ROWS_EVENT = 24,
DELETE_ROWS_EVENT = 25,
INCIDENT_EVENT= 26,
HEARTBEAT_LOG_EVENT= 27,
IGNORABLE_LOG_EVENT= 28,
ROWS_QUERY_LOG_EVENT= 29,
WRITE_ROWS_EVENT = 30,
UPDATE_ROWS_EVENT = 31,
DELETE_ROWS_EVENT = 32,
GTID_LOG_EVENT= 33,
ANONYMOUS_GTID_LOG_EVENT= 34,
PREVIOUS_GTIDS_LOG_EVENT= 35,
ENUM_END_EVENT
/* end marker */
};
当然，内部已经有部分 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()
该函数核心主要是做了以下三个事情：
safe_connect(thd, mysql, mi)
register_slave_on_master(mysql, mi, suppress_warnings)
request_dump(thd, mysql, mi, suppress_warnings)
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
slave 把自己的 slave_id，IP，端口，用户名提交给 Master，用于注册自己到 Master 上去。
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 核心代码为：
kill_zombie_dump_threads(slave_uuid);
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 级别的并行，所以有两个入口
1
2
handle_slave_worker
handle_slave_sql
handle_slave_worker 线程是主要干活的函数，handle_salve_sql 函数作为协调器会启动和分配 worker 线程。
handle_slave_sql 函数主要调用了 slave_worker_exec_job。
slave_worker_exec_job 的主要功能：
job_item= pop_jobs_item(worker, job_item); ev= static_cast Log_event* (job_item- data);
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 主要功能如下：
m_table= const_cast relay_log_info* >
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 的各种数据类型的二进制表现形式，摘录如下
这里有几个比较有意思的地方：
MYSQL_TYPE_STRING 类型，它的 length 占用的字节数是不固定的。如果 string 长度不到大于 255，则需要占用 2 个字节，所以，MySQL 在定义 String 类型的字段时，255 是一个坎，如果字段不可能超过 255 个字节，不建议定义长度的时候超过 255，否则 MySQL 存储数据时会白白浪费一个字节。
MYSQL_TYPE_DATETIME 类型。它存储的格式就是把年 - 月 - 日 时：分：秒按顺序存储下来的，比如：2015-10-10 22:45:55 存储下来就存储为 20151010224545。这种存储格式比较浪费，所以字节数相比 timestamp 占用的也比较多。
关于“MySQL 中 binlog 有什么用”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
