mysql 原理 ~ binlog

一 简介:我们会持续对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服务问题)