一 简介:我们会持续对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,这里要特别注意7 补充: insert update 记录的都不是原始sql,都是更改前后的值,这点要牢记,因为插入的原始语句不一定会指定所有列 binlog_rows_query_log_events 设置这个参数binlog能记录原始的sql
总结:1 记录创建语句本身 2记录执行过程中所生成的语句,并不会记录列所有值 8 特殊语句 create table as select * from 是按照insert单条记录记录的,但是属于一个事务GTID
1 GTID格式会在binlog开头记录之前事务执行过的gtid总和,便于进行扫描
2 5.7的GTID会在binlog每个事务中记录一组基于并行复制的值
3 GTID 每个事务都有唯一的GTID标识
二 binlog针对事务记录点-2 1 记录表信息 1 server_id1 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服务问题)
八 补充
一个完整的事务
at position1 -》事务开始
BGEIN at map event - 》表映射 at DML event -》DML操作 at xid event -》 XID事件 COMMIT at position2 -》 事务结束 从position1-到position2是一个完整的事务