1.什么是binlog？

2.binlog可以用来干什么？

3.怎么样使用binlog?

 

binlog是记录所有数据库表结构变更（例如CREATE、ALTER TABLE…）以及表数据修改（INSERT、

UPDATE、DELETE…）的二进制日志。实际落库产生的日志（事务提交后）。

我们先看一下Mysql数据更新的流程：

 

binlog可以干什么？

• 通过如上所述，我们知道binlog是mysql的已提交日志，是实际落库的，那么如果可以监听到binlog那么我们可以用来处理DB主从同步，跨库同步，数据备份，同步ES，缓存刷新等等

 

怎么样使用binlog？

准备工作

1.检查binlog是否开启

SHOW GLOBAL VARIABLES LIKE ‘log_bin%’; 结果返回不等于ON时代表关闭

可以通过my.ini配置文件(linux中为my.cnf) log-bin=mysql-bin //指定binlog日志文件的名称，可以根据实际需求进行命名。 binlog-format=ROW //设置binlog的格式，下面会解释这三种格式。

 

2.检查binlog格式

SHOW GLOBAL VARIABLES like ' binlog_format%’;

mysql binlog 分为三种模式（STATEMENT，ROW，MIXED）

• Statement（Statement-Based Replication,SBR）：每一条会修改数据的 SQL 都会记录在 binlog 中
• Row（Row-Based Replication,RBR）：不记录 SQL 语句上下文信息，仅保存哪条记录被修改
• Mixed（Mixed-Based Replication,MBR）：Statement 和 Row 的混合体

这里我们设置Row即可

SET GLOBAL binlog_format = 'ROW’;

SET GLOBAL binlog_row_metadata = ‘FULL’;//8.0版本以下不需要设置

现在准备工作完成，可以开始写代码订阅master节点去获取binlog信息了，再次之前我们先了解下 binlog的存储原理

 

3.多文件存储

mysql 将数据库更新操作对应的event记录到本地的binlog文件中，显然在一个文件中记录所有的 event是不可能的，过大的文件会给我们的运维带来麻烦，如删除一个大文件，在I/O调度方面会给我们带来不可忽视的资源开销。

因此，目前基本上所有支持本地文件存储的组件，如MQ、Mysql等，都会控制一个文件的大小。在数据量较多的情况下，就分配到多个文件进行存储。

在mysql中可以通过

show binlog events;

得到binlog的log_name（文件名）和大小以及pos（偏移量位置）

这两个会在后面发送dump到master节点去订阅的时候用到，代表从binlog的哪处位置开始订阅，master 就会在EventStream中发送此文件节点之后的所有数据库变更信息

 

4.Binlog管理事件

所谓binlog管理事件，官方称之为binlog managent events，你可以认为是一些在任何模式下都有可能会出现的事件，不管你的配置binlog_format是Row、Statement还是Mixed。

每个binlog文件总是以Format Description Event作为开始，以Rotate Event结束作为结束。如果你使用的是很古老的Mysql版本中，开始事件也有可能是START EVENT V3，而结束事件是Stop Event。在开始和结束之间，穿插着其他各种事件。

在Event_Type列中，我们看到了三个事件类型：

• Format_desc：也就是我们所说的Format Description Event，是binlog文件的第一个事件。在Info列，我们可以看到，其标明了Mysql Server的版本是8.0，Binlog版本是4。
• Previous_gtids：该事件完整名称为，PREVIOUS_GTIDS_LOG_EVENT。熟悉Mysql 基于GTID复制的

同学应该知道，这是表示之前的binlog文件中，已经执行过的GTID。需要我们开启GTID选项，这个事件才会有值，在后文中，将会详细的进行介绍。

• Rotate：Rotate Event是每个binlog文件的结束事件。在Info列中，我们看到了其指定了下一个 binlog文件的名称是mysql-bin.000004。

5.开始发送一个dump到master节点

serverId代表此slave节点的id（不要跟master节点重复），订阅binlog需要模拟一个slave（从节点）去向master节点发送dump，后续就会接收的订阅返回的事件流信息 filename和position前面提到过的文件名和偏移量

发送成功后就会接收到master节点返回的event信息

每个binlog事件都以一个事件头（event header）开始，然后是一个binlog事件类型特定的数据部分，称为事件体（event body）。

事件体的具体结构与事件类型相关，以QUERY_EVENT类型为例，存储格式如下：

常见的事件类型有：

• FORMAT_DESCRIPTION_EVENT：该部分位于整个文件的头部，每个binlog文件都必定会有唯一一个该event
• PREVIOUS_GTIDS_EVENT：包含在每个binlog的开头，用于描述所有以前binlog所包含的全部*GTID*的一个集合(包括已经删除的binlog)
• GTID_EVENT/ANONYMOUS_GTID_EVENT：每一个Query事务前都会有这样的一个GTID_EVENT，如果未开启则是ANONYMOUS_GTID_EVENT。

事务开始时，执行的BEGIN操作；ROW格式中的DDL操作等

• TABLE_MAP_EVENT：每个DML事务之前，都会有一个TABLE_MAP_EVENT，记录操作对应的表的信息。
• WRITE_ROW_EVENT：插入操作。
• DELETE_ROW_EVENT：删除操作。
• UPDATE_ROW_EVENT：更新操作。记载的是一条记录的完整的变化情况，即从前量变为后量的过程 • XID_EVENT：主要是事务提交的时候回在最后生成一个xid号，有这个便代表事务已经成功提交了
• ROTATE_EVENT：Binlog结束时的事件，与一样仅有一个

 

具体的源码可以通过以下链接去下载：

https://github.com/kogel-net/Kogel.Subscribe

 

尾言

这个轮子是在前两年时候写的，那时候想利用mysql的cdc解决缓存刷新的问题，但是找了一圈发现只有 java开源的轮子例如canal，flinkcdc等，c#社区好像并无此类似轮子就想写一个，完善下c#/.net社区，希望以后.net发展能够越来越好吧。