【Mysql源码分析】基于行的复制实现之“主从复制”

时间 2020-10-25

标签 html mysql sql 安全 bash 服务器 app ide 函数源码分析栏目 HTML 繁體版

原文原文链接

前言

通过对《【Mysql源码分析】基于行的复制实现之“主从关系创建”》了解了主从复制的一些原理，本章内容会深刻对binlog、relaylog作讲解。并对流程作深刻了解。html

在开始交接以前，咱们带着几个问题切入：mysql

如何查看binlog和relaylog事件？
relaylog是如何写入？
binlog是如何同步？
binlog格式如何解析？

1.如何查看binlog和relaylog

在mysql中能够经过以下命令能够查看都有哪些binlog日志，如图1-1：sql

mysql> show binary logs;

<center>图1-1 查看binlog日志</center>安全

Log_name 日志文件名称。
File_size 文件大小。
Encrypted 是否加密“No”表明未加密。

在查看binlog时、主有本身的binlog、从也有本身的binlog。bash

若是要查看最新的binlog，能够经过以下命令查看，如图1-2服务器

mysql> show master status;

<center>图1-2 查看最新binlog</center>app

经过以下命令能够查看当前binlog事件，如图1-3:ide

mysql> show binlog events;

<center>图1-3 查看binlog事件</center>函数

Log_name 日志文件名称。
Pos 表明文件开始的位置。
Event_type 表明事件的类型。
Server_id 是建立事件的服务器ID。
End_log_pos 表明事件在文件中的结束位置，以上面为例，第一次查询的结束位置是125，第二次insert以后文件的开始位置就是从125开始。
Info 表明事件信息，是一段可读的文本内容。

除了查看binlog事件之外，咱们还能够查看relaylog的事件如图1-4所示，查看事件命令以下：源码分析

mysql> show relaylog events;

<center>图1-4 查看relaylog事件</center>
relaylog事件的参数含义和binlog的一致，可参考binlog。

除了查看relaylog事件外，还能够查看relaylog参数，如图1-5所示。经过以下命令能够查看：

mysql> show variables like '%relay%';

<center>图1-5 relaylog参数 </center>

max_relay_log_size：标记relay log 容许的最大值，若是该值为0，则默认值为max_binlog_size(1G)；若是不为0，则max_relay_log_size则为最大的relay_log文件大小；
relay_log：定义relay_log的位置和名称，若是值为空，则默认位置在数据文件的目录，文件名为host_name-relay-bin.nnnnnn；
relay_log_index：同relay_log，定义relay_log的位置和名称；
relay_log_info_file：设置relay-log.info的位置和名称（relay-log.info记录MASTER的binary_log的恢复位置和relay_log的位置）
relay_log_purge：是否自动清空再也不须要中继日志时。默认值为1(启用)。
relay_log_recovery：当slave从库宕机后，假如relay-log损坏了，致使一部分中继日志没有处理，则自动放弃全部未执行的relay-log，而且从新从master上获取日志，这样就保证了relay-log的完整性。默认状况下该功能是关闭的，将relay_log_recovery的值设置为 1时，可在slave从库上开启该功能，建议开启。
relay_log_space_limit：防止中继日志写满磁盘，这里设置中继日志最大限额。但此设置存在主库崩溃，从库中继日志不全的状况，不到万不得已，不推荐使用；
sync_relay_log：这个参数和sync_binlog是同样的，当设置为1时，slave的I/O线程每次接收到master发送过来的binlog日志都要写入系统缓冲区，而后刷入relay log中继日志里，这样是最安全的，由于在崩溃的时候，你最多会丢失一个事务，但会形成磁盘的大量I/O。当设置为0时，并非立刻就刷入中继日志里，而是由操做系统决定什么时候来写入，虽然安全性下降了，但减小了大量的磁盘I/O操做。这个值默认是0，可动态修改，建议采用默认值。
sync_relay_log_info：这个参数和sync_relay_log参数同样，当设置为1时，slave的I/O线程每次接收到master发送过来的binlog日志都要写入系统缓冲区，而后刷入relay-log.info里，这样是最安全的，由于在崩溃的时候，你最多会丢失一个事务，但会形成磁盘的大量I/O。当设置为0时，并非立刻就刷入relay-log.info里，而是由操做系统决定什么时候来写入，虽然安全性下降了，但减小了大量的磁盘I/O操做。这个值默认是0，可动态修改，建议采用默认值。

2.slave_relay_log_info与slave_master_info

slave_relay_log_info和slave_master_info分别为relaylog-info和master-info信息。relaylog-info和master-info信息可使用FILE或这TABLE存储。relaylog-info有三种形式，分为为FILE、TABLE、DUMMY。

<center>图2-1 查看relaylog-info和master-info </center>
经过relay_log_info_repository和master_info_repository能够得知relaylog-info和master-info是用什么形式存储，如图2-1所示。

3.binlog文件格式解析

想了解binlog的格式，能够经过十六进制的形式去查看,如图3-1所示。

<center>图3-1 binlog十六进制格式 </center>
查看十六进制格式可使用hexdump命令，命令格式以下：

#hexdump -C  mysql-bin.000024

经过hexdump获得以下内容：

00000000  fe 62 69 6e 41 93 92 5f  0f 0a 00 00 00 79 00 00  |.binA.._.....y..|
00000010  00 7d 00 00 00 01 00 04  00 38 2e 30 2e 32 30 2d  |.}.......8.0.20-|
00000020  64 65 62 75 67 00 00 00  00 00 00 00 00 00 00 00  |debug...........|
00000030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  00 00 00 00 00 00 00 00  00 00 00 41 93 92 5f 13  |...........A.._.|
00000050  00 0d 00 08 00 00 00 00  04 00 04 00 00 00 61 00  |..............a.|
00000060  04 1a 08 00 00 00 08 08  08 02 00 00 00 0a 0a 0a  |................|
00000070  2a 2a 00 12 34 00 0a 28  01 3a 50 74 ce 41 93 92  |**..4..(.:Pt.A..|
00000080  5f 23 0a 00 00 00 1f 00  00 00 9c 00 00 00 80 00  |_#..............|
00000090  00 00 00 00 00 00 00 00  56 4b 92 11              |........VK..|

也能够mysqlbinlog命令获得binlog信息，如图3-2。命令格式以下：

#mysqlbinlog   --base64-output='decode-rows' mysql-bin.000024

<center>图3-2 binlog信息 </center>
能够经过一张图解析下图3-2中内容，从十六进制格式中解析一下binlog格式，如图3-3所示。

<center>图3-3 binlog格式解析 </center>
能够关注下以下内容和图3-3还有图3-2中关系：

fe 62 69 6e 对应魔术头 0xFE 'bin'

41 93 92 5f timestamp时间戳1603441473，对应时间"2020/10/23 16:24:33"
0f          event_type对应十进制16对应XID_EVENT
0a 00 00 00 server_id 0x0a对应十进制10
79 00 00 00 event_size 对应十进制121
7d 00 00 00 log_pos 对应十进制125
01 00       flags 状态

04 00       binlog version对应版本4
38 2e 30 2e 32 30 2d 64 65 62 75 67 00 00 00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  00 00 00 
mysql-server version 对应版本号8.0.20-debug
41 93 92 5f create-timestamp 建立时间戳，对应1603441473，对应时间2020/10/23 16:24:33 
13          Event-header-length对应19
00 0d 00 08 00 00 00 00  04 00 04 00 00 00 61 00  
04 1a 08 00 00 00 08 08  08 02 00 00 00 0a 0a 0a  
2a 2a 00 12 34 00 0a 28  01   Event-type-header-length 对应41个event类型
3a 50 74 ce  CRC32 对应 0xce74503a  

41 93 92 5f  timestamp对应时间2020/10/23 16:24:33
23           event_type对应35对应PREVIOUS_GTIDS_LOG_EVENT
0a 00 00 00  server_id对应服务ID为10
1f 00 00 00  event_size对应大小31
9c 00 00 00  log_pos对应156
80 00        flags 状态

00 00 00 00 00 00 00 00  Next pos

56 4b 92 11 CRC 0x11924b56

Event-type-header-length对41为何是41？能够看一下源码,对应libbinlogevents/include/binlog_event.h

enum Log_event_type {
  /**
    Every time you add a type, you have to
    - Assign it a number explicitly. Otherwise it will cause trouble
      if a event type before is deprecated and removed directly from
      the enum.
    - Fix Format_description_event::Format_description_event().
  */
  UNKNOWN_EVENT = 0,
  /*
    自MySQL8.0.2以来已弃用。它只是一个占位符，不该该在其余地方使用。
  */
  START_EVENT_V3 = 1,  //起始事件是二进制日志版本1至3的二进制日志的第一个事件。
  QUERY_EVENT = 2,     //查询事件用于向binlog发送文本查询。
  STOP_EVENT = 3,      //中止事件
  ROTATE_EVENT = 4,    //将Rotate事件做为最后一个事件添加到binlog中，以告诉读者接下来要请求的binlog。
  INTVAR_EVENT = 5,   //基于整数的会话变量


  SLAVE_EVENT = 7,   //从事件

  APPEND_BLOCK_EVENT = 9,  //将块数据追加到文件
  DELETE_FILE_EVENT = 11,  //删除文件事件

  RAND_EVENT = 13,         //RAND() 函数的 内部状态。
  USER_VAR_EVENT = 14,     //用户变量
  FORMAT_DESCRIPTION_EVENT = 15, //格式描述事件是binlog版本4的binlog的第一个事件。它描述了其余事件的布局方式。
  XID_EVENT = 16,          //2PC的事务处理ID，在须要时写入 COMMIT。
  BEGIN_LOAD_QUERY_EVENT = 17,  //截断文件并设置块数据
  EXECUTE_LOAD_QUERY_EVENT = 18,

  TABLE_MAP_EVENT = 19,        //基于行的复制中 使用的第一个事件 声明如何定义将要更改的表。

  /**
    V1事件号从5.1.16一直使用到mysql-5.6。 
  */
  WRITE_ROWS_EVENT_V1 = 23,
  UPDATE_ROWS_EVENT_V1 = 24,
  DELETE_ROWS_EVENT_V1 = 25,

  /**
    主发生了不寻常的事
   */
  INCIDENT_EVENT = 26,

  /**
    主机在空闲时间发送的心跳事件确保主机联机状态为从机
  */
  HEARTBEAT_LOG_EVENT = 27,

  /**
    在某些状况下，有必要把不可忽视的东西送过去数据到从机：
    在这种状况下，从机能够处理的数据是用于处理它的代码，
    但若是不是，则能够忽略它辨识。
  */    
  IGNORABLE_LOG_EVENT = 28,
  ROWS_QUERY_LOG_EVENT = 29, //ROWS_EVENT的查询

  /** 行事件的版本2 */
  WRITE_ROWS_EVENT = 30,
  UPDATE_ROWS_EVENT = 31,
  DELETE_ROWS_EVENT = 32,

  GTID_LOG_EVENT = 33,    //gtid 
  ANONYMOUS_GTID_LOG_EVENT = 34, //匿名gtid

  PREVIOUS_GTIDS_LOG_EVENT = 35, //上一个gtid

  TRANSACTION_CONTEXT_EVENT = 36, //事务上下文事件

  VIEW_CHANGE_EVENT = 37,

  /* 准备了相似于Xid的XA事务终端事件 */
  XA_PREPARE_LOG_EVENT = 38,

  /**
    UPDATE_ROWS_事件的扩展，容许根据到 binlog_row_value_options配置中。
  */
  PARTIAL_UPDATE_ROWS_EVENT = 39,

  TRANSACTION_PAYLOAD_EVENT = 40,


  ENUM_END_EVENT /* 终点标记 */
};

在mysql5中只有39个event-type。

基于行复制实现的的事件为TABLE_MAP_EVENT、ROWS_EVENT、ROWS_QUERY_EVENT三大类。
能够看官方： https://dev.mysql.com/doc/internals/en/row-based-replication.html

4.Mysql主从同步源码解析

<center>图4-1 主从同步 </center>
在主从同步过程当中、咱们能够把同步过程分为10个阶段，如图4-1。

通过对以前的《【Mysql源码分析】基于行的复制实现之“主从关系创建”》的学习，得知dump线程会接收到COM_BINLOG_DUMP指令后触发。然而从服务器请求二进制日志流中分为几个参数：

1字节              [12] COM_BINLOG_DUMP
4字节              binlog-pos  binlog对应到位置
2字节              flags       状态
4字节              server-id   服务ID
string[EOF]    binlog-filename 文件名称

当接收到COM_BINLOG_DUMP指令后会触发调用com_binlog_dump方法，com_binlog_dump方法中会调用mysql_binlog_send函数用于发送binlog，如图图4-2所示。

<center>图4-2 发送binlog </center>

void mysql_binlog_send(THD *thd, char *log_ident, my_off_t pos,
                       Gtid_set *slave_gtid_executed, uint32 flags) {
  //log_ident发送binlog名称
  //pos 当前行号，后续会做为开始行号
  Binlog_sender sender(thd, log_ident, pos, slave_gtid_executed, flags);

  sender.run();
}

在调用mysql_binlog_send方法后，会调用Binlog_sender::send_events方法发送事件，在发送事件时会调用Binlog_sender::check_event_type方法对事件进行检测,如图4-3。

<center>图4-3 事件检测方法 </center>
用Binlog_sender::check_event_type检测方法原型以下：

bool Binlog_sender::check_event_type(Log_event_type type, const char *log_file,
                                     my_off_t log_pos) {
  if (type == binary_log::ANONYMOUS_GTID_LOG_EVENT) {
    /*
     一般状况下，当自动位置被启用，由于主设备和从设备
     若是主机未使用GTID_MODE=ON，则拒绝链接。
     可是，若是主机在链接后更改了GTID_模式初始化，
     或者若是从属请求复制出如今最后一个匿名事件以前
     的事务，则这可能发生。而后生成此错误以阻止发送
     到从属服务器的匿名事务。
    */
    if (m_using_gtid_protocol) { //判断是否使用gtid
      DBUG_EXECUTE_IF("skip_sender_anon_autoposition_error",
                      { return false; };);
      char buf[MYSQL_ERRMSG_SIZE];
      snprintf(buf, MYSQL_ERRMSG_SIZE,
               ER_THD(m_thd, ER_CANT_REPLICATE_ANONYMOUS_WITH_AUTO_POSITION),
               log_file, log_pos);
      set_fatal_error(buf);
      return true;
    }
    /*
      一般状况下，当master有GTID_MODE=ON，由于当GTID_MODE=ON。可是，若是主控形状发生更改，则可能会发生这种状况当从属服务器还没有复制全部匿名交互。
    */
    else if (get_gtid_mode_from_copy(GTID_MODE_LOCK_NONE) == GTID_MODE_ON) {
      char buf[MYSQL_ERRMSG_SIZE];
      snprintf(buf, MYSQL_ERRMSG_SIZE,
               ER_THD(m_thd, ER_CANT_REPLICATE_ANONYMOUS_WITH_GTID_MODE_ON),
               log_file, log_pos);
      set_fatal_error(buf);
      return true;
    }
  } else if (type == binary_log::GTID_LOG_EVENT) {
    /*
      一般状况下，当主服务器有GTID_MODE=OFF，由于当
      GTID_MODE=OFF。可是，若是主控形状发生更改，则
      可能会发生这种状况当从机还没有复制全部GTID时，GTID_MODE关闭交互。
    */
    if (get_gtid_mode_from_copy(GTID_MODE_LOCK_NONE) == GTID_MODE_OFF) {
      char buf[MYSQL_ERRMSG_SIZE];
      snprintf(buf, MYSQL_ERRMSG_SIZE,
               ER_THD(m_thd, ER_CANT_REPLICATE_GTID_WITH_GTID_MODE_OFF),
               log_file, log_pos);
      set_fatal_error(buf);
      return true;
    }
  }
  return false;
}

<center>图4-4 Log_event::write </center>
在写入binlog时会调用Log_event::write进行写入，如图4-4。Log_event::write在log_event.h头文件中。

写入master-info信息调度以下：

(lldb) bt
* thread #36, stop reason = breakpoint 8.1
  * frame #0: 0x0000000109a10c80 mysqld`Master_info::write_info(this=0x00007fe416209200, to=0x00007fe418204230) at rpl_mi.cc:666
    frame #1: 0x0000000109a0e9ba mysqld`Master_info::flush_info(this=0x00007fe416209200, force=false) at rpl_mi.cc:380
    frame #2: 0x0000000109a987eb mysqld`flush_master_info(mi=0x00007fe416209200, force=false, need_lock=false, do_flush_relay_log=false) at rpl_slave.cc:1424
    frame #3: 0x0000000109ab4565 mysqld`queue_event(mi=0x00007fe416209200, buf="\a�\x8e_\"\n", event_len=77, do_flush_mi=true) at rpl_slave.cc:7956
    frame #4: 0x0000000109a9e063 mysqld`::handle_slave_io(arg=0x00007fe416209200) at rpl_slave.cc:5462
    frame #5: 0x000000010ac5a6c5 mysqld`pfs_spawn_thread(arg=0x00007fe4175b28b0) at pfs.cc:2854
    frame #6: 0x00007fff7e063305 libsystem_pthread.dylib`_pthread_body + 126
    frame #7: 0x00007fff7e06626f libsystem_pthread.dylib`_pthread_start + 70
    frame #8: 0x00007fff7e062415 libsystem_pthread.dylib`thread_start + 13

写入Relay-log-info信息调度以下：

(lldb) bt
* thread #41, stop reason = breakpoint 2.1
  * frame #0: 0x000000010c36f990 mysqld`Relay_log_info::write_info(this=0x00007f8a53de3400, to=0x00007f8a5512af50) at rpl_rli.cc:2200
    frame #1: 0x000000010c3677e1 mysqld`Relay_log_info::flush_info(this=0x00007f8a53de3400, force=true) at rpl_rli.cc:1905
    frame #2: 0x000000010c371fe8 mysqld`Relay_log_info::commit_positions(this=0x00007f8a53de3400) at rpl_rli.cc:2730
    frame #3: 0x000000010a4b72eb mysqld`Relay_log_info::pre_commit(this=0x00007f8a53de3400) at rpl_rli.h:1986
    frame #4: 0x000000010a4b6655 mysqld`ha_commit_trans(thd=0x00007f8a5605fa00, all=true, ignore_global_read_lock=false) at handler.cc:1656
    frame #5: 0x000000010aefeab4 mysqld`trans_commit(thd=0x00007f8a5605fa00, ignore_global_read_lock=false) at transaction.cc:241
    frame #6: 0x000000010ab202d3 mysqld`mysql_create_db(thd=0x00007f8a5605fa00, db="t136", create_info=0x000070000d37a898) at sql_db.cc:405
    frame #7: 0x000000010ac6f026 mysqld`mysql_execute_command(thd=0x00007f8a5605fa00, first_level=true) at sql_parse.cc:3660
    frame #8: 0x000000010ac676ad mysqld`mysql_parse(thd=0x00007f8a5605fa00, parser_state=0x000070000d37e028) at sql_parse.cc:5306
    frame #9: 0x000000010c24dc6c mysqld`Query_log_event::do_apply_event(this=0x00007f8a520d0620, rli=0x00007f8a53de3400, query_arg="create database t136", q_len_arg=20) at log_event.cc:4804
    frame #10: 0x000000010c24af13 mysqld`Query_log_event::do_apply_event(this=0x00007f8a520d0620, rli=0x00007f8a53de3400) at log_event.cc:4415
    frame #11: 0x000000010c2458fe mysqld`Log_event::apply_event(this=0x00007f8a520d0620, rli=0x00007f8a53de3400) at log_event.cc:3241
    frame #12: 0x000000010c4047e7 mysqld`apply_event_and_update_pos(ptr_ev=0x000070000d37f860, thd=0x00007f8a5605fa00, rli=0x00007f8a53de3400) at rpl_slave.cc:4350
    frame #13: 0x000000010c3f2032 mysqld`exec_relay_log_event(thd=0x00007f8a5605fa00, rli=0x00007f8a53de3400, applier_reader=0x000070000d3803d8, in=0x00007f8a520d0620) at rpl_slave.cc:4867
    frame #14: 0x000000010c3db543 mysqld`::handle_slave_sql(arg=0x00007f8a52b43200) at rpl_slave.cc:7022
    frame #15: 0x000000010d5936c5 mysqld`pfs_spawn_thread(arg=0x00007f8a554bcbf0) at pfs.cc:2854
    frame #16: 0x00007fff7e063305 libsystem_pthread.dylib`_pthread_body + 126
    frame #17: 0x00007fff7e06626f libsystem_pthread.dylib`_pthread_start + 70
    frame #18: 0x00007fff7e062415 libsystem_pthread.dylib`thread_start + 13

Master断点

#发送binlog
(lldb)b mysql_binlog_send

#发送binlog包
(lldb)b Binlog_sender::send_packet

#循环事件
(lldb)b Binlog_sender::run

#发送binlog
(lldb)b Binlog_sender::send_binlog

#发送心跳包事件
(lldb)b Binlog_sender::send_heartbeat_event

Slave 断点

#读取头文件事件
b Binlog_event_data_istream::read_event_header

#填充时间数据
b Binlog_event_data_istream::fill_event_data

#读取下一个事件
b Rpl_applier_reader::read_next_event

#slave sal处理
b handle_slave_sql

#写入relay-log-info
b Relay_log_info::write_info

#relay_log事件
b exec_relay_log_event  

#写入binlog或者relaylog断点
b handler::ha_write_row
b MYSQL_BIN_LOG::write_event
b binlog_cache_data::write_event

#写入relaylog以后操做
MYSQL_BIN_LOG::after_write_to_relay_log

#写入binlog
b MYSQL_BIN_LOG::write_buffer
b MYSQL_BIN_LOG::Binlog_ofile::write

总结

经过“show binary logs;” 能够查看binlog日志。
经过“show relaylog events;”能够查看relaylog事件。
在mysql8.0.20中有41个事件,mysql5.1中有39个。
基于行复制实现的的事件为TABLE_MAP_EVENT、ROWS_EVENT、ROWS_QUERY_EVENT三大类。
relaylog-info和binlog-info可使用file或者table形式记录。

参考献文

复制协议
https://dev.mysql.com/doc/internals/en/replication-protocol.html

事件含义
https://dev.mysql.com/doc/internals/en/event-meanings.html

基于行的二进制日志记录
[https://dev.mysql.com/doc/int...
](https://dev.mysql.com/doc/int...