如何动态监控mysql binlog

发布网友 发布时间：2022-04-21 08:31

我来回答

共3个回答

懂视网 时间：2022-04-29 20:27

GitHub地址：https://github.com/alibaba/canal

在介绍Canal内部原理之前，首先来了解一下MySQL Master/Slave同步原理：

1. MySQL master启动binlog机制，将数据变更写入二进制日志（binary log, 其中记录叫做二进制日志事件binary log events，可以通过show binlog events进行查看）
2. MySQL slave（I/O thread）将master的binary log events拷贝到它的中继日志（relay log）
3. MySQL slave（SQL thread）重放relay log中事件，将数据变更反映它自己的数据中

Canal工作原理：

1. Canal模拟MySQL slave的交互协议，伪装自己为MySQL slave，向MySQL master发送dump协议
2. MySQL master收到dump请求，开始推送binary log给slave（也就是canal）
3. Canal解析binary log对象（原始为byte流）

简而言之，Canal是通过模拟成为MySQL的slave，监听MySQL的binlog日志来获取数据。当把MySQL的binlog设置为row模式以后，可以获取到执行的每一个Insert/Update/Delete的脚本，以及修改前和修改后的数据，基于这个特性，Canal就能高效的获取到MySQL数据的变更。

Canal架构：

说明：
server代表一个Canal运行实例，对应于一个jvm
instance对应于一个数据队列（1个server对应1..n个instance)

EventParser：数据源接入，模拟slave协议和master进行交互，协议解析

EventSink：Parser和Store连接器，主要进行数据过滤，加工，分发的工作

EventStore：负责存储

MemoryMetaManager：增量订阅和消费信息管理器

Event Parser设计：

整个parser过程大致可分为以下几步：

1. Connection获取上一次解析成功的log position（如果是第一次启动，则获取初始指定的位置或者是当前数据库的binlog log position）
2. Connection建立连接，向MySQL master发送BINLOG_DUMP请求
3. MySQL开始推送binary Log接收到的binary Log
4. 通过BinlogParser进行协议解析，补充一些特定信息。如补充字段名字、字段类型、主键信息、unsigned类型处理等
5. 将解析后的数据传入到EventSink组件进行数据存储（这是一个阻塞操作，直到存储成功）
6. 定时记录binary Log位置，以便重启后继续进行增量订阅

如果需要同步的master宕机，可以从它的其他slave节点继续同步binlog日志，避免单点故障。


Event Sink设计：

EventSink主要作用如下：

数据过滤：支持通配符的过滤模式，表名，字段内容等

数据路由/分发：解决1:n（1个parser对应多个store的模式）

数据归并：解决n:1（多个parser对应1个store）

数据加工：在进入store之前进行额外的处理，比如join

数据1:n业务

为了合理的利用数据库资源， 一般常见的业务都是按照schema进行隔离，然后在MySQL上层或者dao这一层面上，进行一个数据源路由，屏蔽数据库物理位置对开发的影响，阿里系主要是通过cobar/tddl来解决数据源路由问题。所以，一般一个数据库实例上，会部署多个schema，每个schema会有由1个或者多个业务方关注。

数据n:1业务

同样，当一个业务的数据规模达到一定的量级后，必然会涉及到水平拆分和垂直拆分的问题，针对这些拆分的数据需要处理时，就需要链接多个store进行处理，消费的位点就会变成多份，而且数据消费的进度无法得到尽可能有序的保证。所以，在一定业务场景下，需要将拆分后的增量数据进行归并处理，比如按照时间戳/全局id进行排序归并。

Event Store设计：

支持多种存储模式，比如Memory内存模式。采用内存环装的设计来保存消息，借鉴了Disruptor的RingBuffer的实现思路。

RingBuffer设计：

定义了3个cursor：

put：Sink模块进行数据存储的最后一次写入位置（同步写入数据的cursor）

get：数据订阅获取的最后一次提取位置（同步获取的数据的cursor）

ack：数据消费成功的最后一次消费位置

借鉴Disruptor的RingBuffer的实现，将RingBuffer拉直来看：

实现说明：

1. put/get/ack cursor用于递增，采用long型存储。三者之间的关系为put>=get>=ack
2. buffer的get操作，通过取余或者&操作。(&操作：cusor & (size - 1) , size需要为2的指数，效率比较高)

Instance设计：

instance代表了一个实际运行的数据队列，包括了EventPaser、EventSink、EventStore等组件。抽象了CanalInstanceGenerator，主要是考虑配置的管理方式：

manager方式：和你自己的内部web console/manager系统进行对接。(目前主要是公司内部使用)

spring方式：基于spring xml + properties进行定义，构建spring配置。

Server设计：

server代表了一个Canal运行实例，为了方便组件化使用，特意抽象了Embeded(嵌入式)/Netty(网络访问)的两种实现。

增量订阅/消费设计：

具体的协议格式，可参见：CanalProtocol.proto。数据对象格式：EntryProtocol.proto

Entry
 Header
 logfileName [binlog文件名]
 logfileOffset [binlog position]
 executeTime [binlog里记录变更发生的时间戳]
 schemaName [数据库实例]
 tableName [表名]
 eventType [insert/update/delete类型]
 entryType [事务头BEGIN/事务尾END/数据ROWDATA]
 storeValue [byte数据,可展开，对应的类型为RowChange]

RowChange
isDdl [是否是ddl变更操作，比如create table/drop table]
sql [具体的ddl sql]
rowDatas [具体insert/update/delete的变更数据，可为多条，1个binlog event事件可对应多条变更，比如批处理]
beforeColumns [Column类型的数组]
afterColumns [Column类型的数组]

Column
index [column序号]
sqlType [jdbc type]
name [column name]
isKey [是否为主键]
updated [是否发生过变更]
isNull [值是否为null]
value [具体的内容，注意为文本]

针对上述的补充说明：

1.可以提供数据库变更前和变更后的字段内容，针对binlog中没有的name、isKey等信息进行补全

2.可以提供ddl的变更语句

Canal HA机制：

Canal的HA实现机制是依赖zookeeper实现的，主要分为Canal server和Canal client的HA。

Canal server:为了减少对MySQL dump的请求，不同server上的instance要求同一时间只能有一个处于running状态，其他的处于standby状态。

Canal client:为了保证有序性，一份instance同一时间只能由一个Canal client进行get/ack/rollback操作，否则客户端接收无法保证有序。


Canal Server HA架构图：

大致步骤：

1. Canal server要启动某个Canal instance时都先向Zookeeper进行一次尝试启动判断 (实现：创建EPHEMERAL节点，谁创建成功就允许谁启动)
2. 创建Zookeeper节点成功后，对应的Canal server就启动对应的Canal instance，没有创建成功的Canal instance就会处于standby状态
3. 一旦Zookeeper发现Canal server A创建的节点消失后，立即通知其他的Canal server再次进行步骤1的操作，重新选出一个Canal server启动instance
4. Canal client每次进行connect时，会首先向Zookeeper询问当前是谁启动了Canal instance，然后和其建立链接，一旦链接不可用，会重新尝试connect

Canal Client的方式和Canal server方式类似，也是利用Zookeeper的抢占EPHEMERAL节点的方式进行控制。

关注微信公众号：大数据学习与分享，获取更对技术干货

监听MySQL的binlog日志工具分析：Canal

标签：数据存储   lin   mbed   head   join   padding   数据源   项目   文本   

热心网友 时间：2022-04-29 17:35

有两种方法，一种方法使用mysql的check table和repair table 的sql语句，另一种方法是使用MySQL提供的多个myisamchk, isamchk数据检测恢复工具。前者使用起来比较简便。推荐使用。
1. check table 和 repair table
登陆mysql 终端：
mysql -uxxxxx -p dbname
check table tabTest;
如果出现的结果说Status是OK，则不用修复，如果有Error，可以用：
repair table tabTest;
进行修复，修复之后可以在用check table命令来进行检查。在新版本的phpMyAdmin里面也可以使用check/repair的功能。
2. myisamchk, isamchk
其中myisamchk适用于MYISAM类型的数据表，而isamchk适用于ISAM类型的数据表。这两条命令的主要参数相同，一般新的系统都使用MYISAM作为缺省的数据表类型，这里以myisamchk为例子进行说明。当发现某个数据表出现问题时可以使用：
myisamchk tablename.MYI
进行检测，如果需要修复的话，可以使用：
myisamchk -of tablename.MYI
关于myisamchk的详细参数说明，可以参见它的使用帮助。需要注意的时在进行修改时必须确保MySQL服务器没有访问这个数据表，保险的情况下是最好在进行检测时把MySQL服务器Shutdown掉。
另外可以把下面的命令放在你的rc.local里面启动MySQL服务器前：
[ -x /tmp/mysql.sock ] && /pathtochk/myisamchk -of /DATA_DIR/*/*.MYI
其中的/tmp/mysql.sock是MySQL监听的Sock文件位置，对于使用RPM安装的用户应该是/var/lib/mysql/mysql.sock，对于使用源码安装则是/tmp/mysql.sock可以根据自己的实际情况进行变更，而pathtochk则是myisamchk所在的位置，DATA_DIR是你的MySQL数据库存放的位置。
需要注意的时，如果你打算把这条命令放在你的rc.local里面，必须确认在执行这条指令时MySQL服务器必须没有启动！检测修复所有数据库(表)

热心网友 时间：2022-04-29 18:53

当启动Binlog后，事务会产生Binlog Event，这些Event被看做事务数据的一部分。因此要保证事务的Binlog Event和InnoDB引擎中的数据的一致性。所以带Binlog的CrashSafe要求MySQL宕机重启后能够保证：
- 所有已经提交的事务的数据仍然存在。
- 所有没有提交的事务的数据自动回滚。
- 所有已经提交了的事务的Binlog Event也仍然存在。
- 所有没有提交事务没有记录Binlog Event。
这些要求很好理解，如果重启后数据还在，但是Binlog Event没有了，就没办法复制到其他节点上了。如果重启后，数据没了，但是Binlog Event还在，那么不存在的数据就会被复制到其他节点上，从而导致主从的不一致。

为了保证带Binlog的CrashSafe，MySQL内部使用的两阶段提交(Two Phase Commit)。

2 - MySQL的Two Phase Commit(2PC)
在开启Binlog后，MySQL内部会自动将普通事务当做一个XA事务来处理：
- 自动为每个事务分配一个唯一的ID
- COMMIT会被自动的分成Prepare和Commit两个阶段。
- Binlog会被当做事务协调者(Transaction Coordinator)，Binlog Event会被当做协调者日志。
想了解2PC，可以参考文档：【https://en.wikipedia.org/wiki/Two-phase_commit_protocol。】

- 分布式事务ID(XID)
使用2PC时，MySQL会自动的为每一个事务分配一个ID，叫XID。XID是唯一的，每个事务的XID都不相同。XID会分别被Binlog和InnoDB记入日志中，供恢复时使用。MySQ内部的XID由三部分组成：
- 前缀部分
前缀部分是字符串"MySQLXid"
- Server ID部分
当前MySQL的server_id
- query_id部分
为了保证XID的的唯一性，数字部分使用了query_id。MySQL内部会自动的为每一个语句分配一个query_id，全局唯一。
参考代码：sql/xa。h的struct xid_t结构。

- 事务的协调者Binlog
Binlog在2PC中充当了事务的协调者（Transaction Coordinator）。由Binlog来通知InnoDB引擎来执行prepare，commit或者rollback的步骤。事务提交的整个过程如下：
1. 协调者准备阶段(Prepare Phase)
告诉引擎做Prepare，InnoDB更改事务状态，并将Redo Log刷入磁盘。
2. 协调者提交阶段(Commit Phase)
2.1 记录协调者日志，即Binlog日志。
2.2 告诉引擎做commit。
注意：记录Binlog是在InnoDB引擎Prepare(即Redo Log写入磁盘)之后，这点至关重要。

在MySQ的代码中将协调者叫做tc_log。在MySQL启动时，tc_log将被初始化为mysql_bin_log对象。参考sql/binlog.cc中的init_server_components()：
if (opt_bin_log) tc_log= &mysql_bin_log;

而在事务提交时，会依次执行：
tc_log->prepare()；
tc_log->commit()；
参考代码：sql/binlog.cc中的ha_commit_trans()。当mysql_bin_log是tc_log时，prepare和commit的代码在sql/binlog.cc中：

MYSQL_BIN_LOG::prepare()；
MYSQL_BIN_LOG::commit()；

-协调者日志Xid_log_event
作为协调者，Binlog需要将事务的XID记入日志，供恢复时使用。Xid_log_event有以下几个特点：
- 仅记录query_id
因为前缀部分不变，server_id已经记录在Event Header中，Xid_log_event中只记录query_id部分。
- 标志事务的结束
在Binlog中相当于一个事务的COMMIT语句。
一个事务在Binlog中看起来时这样的：
Query_log_event("BEGIN");DML产生的events; Xid_log_event;

- DDL没有BEGIN，也没有Xid_log_event 。
- 仅InnoDB的DML会产生Xid_log_event
因为MyISAM不支持2PC所以不能用Xid_log_event ，但会有COMMIT Event。
Query_log_event("BEGIN");DML产生的events;Query_log_event("COMMIT");

问题：Query_log_event("COMMIT")和Xid_log_event 有不同的影响吗？

- Xid_log_event 中的Xid可以帮助master实现CrashSafe。
- Slave的CrashSafe不依赖Xid_log_event
事务在Slave上重做时，会重新产生XID。所以Slave服务器的CrashSafe并不依赖于Xid_log_event 。Xid_log_event 和Query_log_event("COMMIT")，只是作为事务的结尾，告诉Slave Applier去提交这个事务。因此二者在Slave上的影响是一样的。

3 - 恢复(Recovery)
这个机制是如何保证MySQL的CrashSafe的呢，我们来分析一下。这里我们假设用户设置了以下参数来保证可靠性：

- 恢复前事务的状态
在恢复开始前事务有以下几种状态：
- InnoDB中已经提交
根据前面2PC的过程，可知Binlog中也一定记录了该事务的的Events。所以这种事务是一致的不需要处理。
- InnoDB中是prepared状态，Binlog中有该事务的Events。
需要通知InnoDB提交这些事务。
- InnoDB中是prepared状态，Binlog中没有该事务的Events。
因为Binlog还没记录，需要通知InnoDB回滚这些事务。
- Before InnoDB Prepare
事务可能还没执行完，因此InnoDB中的状态还没有prepare。根据2PC的过程，Binlog中也没有该事务的events。 需要通知InnoDB回滚这些事务。

- 恢复过程
从上面的事务状态可以看出：恢复时事务要提交还是回滚，是由Binlog来决定的。
- 事务的Xid_log_event 存在，就要提交。
- 事务的Xid_log_event 不存在，就要回滚。

恢复的过程非常简单：
- 从Binlog中读出所有的Xid_log_event
- 告诉InnoDB提交这些XID的事务
- InnoDB回滚其它的事务