db-cdc之mysql 深入了解并使用binlog

  • db-cdc之mysql 深入了解并使用binlog已关闭评论
  • 33 次浏览
  • A+
所属分类:.NET技术
摘要

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


1.什么是binlog?

2.binlog可以用来干什么?

3.怎么样使用binlog?

 

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

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

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

db-cdc之mysql 深入了解并使用binlog

 

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(偏移量位置)

db-cdc之mysql 深入了解并使用binlog

这两个会在后面发送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节点

db-cdc之mysql 深入了解并使用binlog

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

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

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

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

db-cdc之mysql 深入了解并使用binlog

常见的事件类型有:

  • 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发展能够越来越好吧。