MySQL主从复制主库binlog dump线程源码分析

在之前的文章《mysql主从复制io线程源码分析》，我们分析了MySQL从库的io线程工作的主要过程，大致回顾一下，如下：

1. 连接主库
2. 发送COM_REGISTER_SLAVE命令注册从库
3. 发送COM_BINLOG_DUMP_GTID命令请求拉取binlog

下面将结合源码，分析一下主库接收到从库io线程发送过来的命令后，是如何具体处理的。

MySQL源码版本：5.7.19

原文地址：
https://mytecdb.com/blogDetail.php?id=86

1. 注册从库

主库在接收到从库发送的COM_REGISTER_SLAVE命令后，会调用register_slave函数完成从库的注册。主要的执行逻辑如下：

获取从库发送的与注册相关的一些数据，包括从库的server_id，report_host，report_user，report_password，port等等，这些数据会被存放在一个叫做SLAVE_INFO的结构里，这个结构最终会被放到slave_list变量中，slave_list的类型是一个HASH表。slave_list是一个全局变量，位于源码文件 sql/rpl_master.cc，这个变量在用户执行show slave hosts时也会用到。

如果slave_list这个HASH表中已经有从库的信息了，也就是包含相同server_id的从库信息已经存在，那么会先删掉该从库信息，再把新的加进去。

2. 发送binlog

主库在接收到从库发送的COM_BINLOG_DUMP_GTID命令后，会调用com_binlog_dump_gtid函数处理从库拉取binlog的请求。主要的执行逻辑如下：

1. 获取从库发送的binlog相关信息，包括server_id，binlog名称，binlog位置，binlog大小，gtid信息等等。
2. 检查是否已经存在与该从库关联的binlog dump线程，如果存在，结束该binlog dump线程。为什么会已经存在binlog dump线程？在某些场景下，比如从库io线程停止，这时主库的binlog dump线程正好在等待binlog更新，即等待主库写入数据，如果主库一直没有写入数据，dump线程就会等待很长时间，如果这时从库io线程重连到主库，就会发现主库已经存在与该从库对应的dump线程。所以主库在处理从库binlog dump请求时，先检查是否已经存在dump线程。
3. 调用mysql_binlog_send函数，向从库发送binlog。这个函数内部实际是通过一个C++类Binlog_sender来实现的，该类在源码文件sql/rpl_binlog_sender.h中定义，调用该类的run成员函数来发送binlog。
4. Binlog_sender类的run成员函数，主要逻辑是通过多个while嵌套循环，依次读取binlog文件，binlog文件中的event，将event发送给从库。如果event已经在从库中应用，则忽略该event。当读到最新的binlog时，如果所有event都已经发送完成，那么线程会等待binlog更新事件update_cond，有新的binlog event写入后，会广播通知所有等待update_cond事件的线程开始工作，也包括dump线程。dump线程在等待update_cond事件时有一个超时时间，这个时间就是master_heartbeat_period，即主库dump线程与从库io线程的心跳时间间隔，这个值在从库执行change master 时设置，启动io线程时把该值传递给主库，主库dump线程等待update_cond超时后，将会给从库发送一个heartbeat event，之后会继续等待update_cond事件。上述过程会一直循环，直到dump线程被kill或者遇到其他错误。
5. 当执行逻辑从Binlog_sender类内部的while循环退出，紧接着会调用unregister_slave函数注销从库的注册。这个时候在主库上执行show slave hosts，就会发现从库的信息已经没有了。

3. 思考一个问题

从库执行stop slave，我们立即在主库上执行show slave hosts，发现从库信息仍然存在，过一段时间，大概60秒左右，再次执行，才发现从库信息消失，这是为什么？

从库执行stop slave，只是将io线程结束掉，并不会通知主库dump线程，主库dump线程在给从库发送binlog event或者心跳包时，由于从库io线程已经结束，网络包无响应，主库等待net.ipv4.tcp_fin_timeout（默认60秒）后，报异常，退出Binlog_sender内部的while循环，调用unregister_slave函数注销从库的注册，此时再次在主库执行show slave hosts，就不会再看到从库的信息了。

---

附录：

主要源码文件：
sql/rpl_master.h
sql/rpl_master.cc

sql/rpl_binlog_sender.h
sql/rpl_binlog_sender.cc