一 简介:我们会持续对binlog进行分析,但是不深入代码
二 版本 5.6
格式
GTID和传统格式
传统格式
一 binlog针对具体事务注意点-1
1 update会记录更改前和更改后所有列的值
2 delete会记录删除前所有列的值
3 insert会记录插入的具体sql
4 ddl语句只会记录语句本身,不会记录影响行
5 dcl语句不会记录
6 特殊类型
1 trigger 1 记录产生数据更新的sql语句。对于调用触发器后产生的数据更新，并不记录到binlog中
2 function 如果函数中有数据改变，那函数的调用语句（包括select语句）将记录到binlog中
3 event event触发事件后，更新数据的sql语句将记入binlog，event功能默认是关闭的。在master上定义event后，slave同步event并将其标示为SLAVESIDE_DISABLED,这里要特别注意
总结:1 记录创建语句本身 2记录执行过程中所生成的语句,并不会记录列所有值
7 特殊语句
create table as select * from 是按照insert单条记录记录的,但是属于一个事务
GTID
1 GTID格式会在binlog开头记录之前事务执行过的gtid总和,便于进行扫描
2 5.7的GTID会在binlog每个事务中记录一组基于并行复制的值
3 GTID 每个事务都有唯一的GTID标识
二 binlog针对事务记录点-2
1 记录表信息
1 server_id
1 binlog执行事务所在数据库的server_id,
2 哪怕在多级复制中级联生成的binlog,集群server_id不会改变,一定是master的server_id
3 双主架构中,如果判断出是自己的server_id,就不会执行了,解决了不停执行事务的死循环
2 CRC32 binlog_checksum加密协议,MGR架构不支持
3 Table_map 目标的库+表
4 Table_id 目标表的table_id
5 type_evnet 对应 delete_event,update_event,insert_event 删 更新和插入(binlog_row_image=FULL(记录全部字段)=MINIMAL(记录关键字段）
6 具体的事务
包含具体的值,详见上述
7 Xid event 表示事务被正确的提交了
三 恢复数据场景
DML场景
1 delete-table全表/部分 数据
2 update-table全表/部分 数据
解决办法 根据binlog恢复
DDL场景
1 truncate/drop table
2 modify tale
解决办法 根据历史备份+binlog恢复
通用解决办法 根据最新的历史备份+之后的binlog进行恢复,然后数据导入
四 备份
本地binlog默认保留7天,利用 binlog_server进行异地binlog备份
六 解析工具
canal以及扩展otter 程序持续读取binlog的工具,非常普遍的应用
mysqlbinlog 系统自带的分析binlog工具,进行需求统计和回滚binlog
binlog2sql/MyFlash 第三方分析并回滚binlog工具
七 应用场景
1 为从库和其他应用比如(canal)提高操作实时解析同步功能
2 历史数据进行恢复(全量binlog可以保证能恢复任意时间点)
3 历史数据进行查看(全量binlog可以查看任何时间段的数据)
4 对库/表进行操作统计(1 排查主从延迟问题 2 排查高IO服务问题)