show binglog events 查看第一个binlog文件，我们也可以通过in参数来指定，假设我们想看的文件名是mysql-bin.000001，那么可以使用命令show binlog events in 'mysql-bin.000001'来查看指定的binlog文件
接下来我们来看看我们在MySQL中的操作所对应的binlog内容分别是什么。
初始化
我们上面提到过，binlog是由一个一个的event组成的。从MySQL 5.0开始，binlog的第一个event都为Format_desc，位于图中的Event_type那一列。可以看到内容为Server ver;5.6.50-log, Binlog ver: 4，说明当前使用的MySQL版本为5.6.50，Binlog的版本是V4。
创建数据库
然后我创建了一个名为student的DB，其Event_type是Query，这个event的内容为CREATE DATABASE student DEFAULT CHARACTER SET = utf8mb4，一个建库语句。
新建表
然后我创建了一个名为student的表，Event_type也是Query，内容为use student; CREATE TABLE student (id INT(11) UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT)，一个建表语句。
插入数据
然后我们执行INSERT语句给该表插入两行数据，再次查看binlog。
INSERT INTO `student` (`id`, `name`) VALUES (NULL, '张三');INSERT INTO `student` (`id`, `name`) VALUES (NULL, '李四');
可以看到每次INSERT都会开启一个事务，你可能会疑惑，我们只是简单的执行了INSERT语句，没有显示的开启事务。那为什么会有事务产生呢？
这是因为MySQL采用了自动提交（AUTOCOMMIT）的机制，我使用的InnoDB存储引擎，是支持事务的，所有的用户活动都发生在事务中。我们可以通过show variables like '%AUTOCOMMIT%';命令查看，如果结果是ON则代表是开启的。
1.3 复制的核心步骤我们假设主库已经开启了binlog，并正常的记录binlog。
首先从库启动I/O线程，跟主库建立客户端连接。
主库启动binlog dump线程，读取主库上的binlog event发送给从库的I/O线程，I/O线程获取到binlog event之后将其写入到自己的Relay Log中。
然后从库启动SQL线程，将Relay中的数据进行重放，完成从库的数据更新。
总结来说，主库上只会有一个线程，而从库上则会有两个线程。
relay log其实和binlog没有太大的区别，在MySQL 4.0 之前是没有Relay Log这部分的，整个过程中只有两个线程。但是这样也带来一个问题，那就是复制的过程需要同步的进行，很容易被影响，而且效率不高。例如主库必须要等待从库读取完了才能发送下一个binlog事件。这就有点类似于一个阻塞的信道和非阻塞的信道。
阻塞信道就跟你在柜台一样，你要递归柜员一个东西，但是你和柜员之间没有可以放东西的地方，你就只能一直把文件拿着，直到柜员接手；而非阻塞信道就像你们之间有个地方可以放文件，你就直接放上去就好了，不用等柜员接手。
引入了Relay Log之后，让原本同步的获取事件、重放事件解耦了，两个步骤可以异步的进行，Relay Log充当了缓冲区的作用。Relay Log有一个relay-log.info的文件，用于记录当前复制的进度，下一个事件从什么Pos开始写入，该文件由SQL线程负责更新。
1.5 Relay Log核心参数接下来让我们了解一下Relay Log的核心参数。
max_relay_log_size 中继日志的最大size，默认值0，如果为0就会取默认的size 1G，否则就为设置的值
relay_log 定义relay的名称，默认为主机名+relay-bin，例如像hostname-relay-bin
relay_log_basename 中继日志的全路径，即路径 + 文件名，例如/path/to/hostname-relay-bin，最大长度为256