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

你可能感兴趣的:(MySQL主从复制主库binlog dump线程源码分析)