intvar mysql_mysql binlog格式解析(一)
该楼层疑似违规已被系统折叠 隐藏此楼查看此楼
参考源:
1、源码log_event.h log_event.cc pack.c
2、internals-en.epub
一、目的
本系列文件主要为了说明
1、为什么说row格式较statement更占空间
2、为什么说row格式的binlog更加安全
3、INSERT/UPDATE/DELETE是生成的row binlog如何直接看懂二进制格式
4、DDL生成的binlog是怎么样的
5、INSERT SELECT/CREATE TABLE 如何生成的row binlog
二、使用版本和数字显示
本系列文章重要解释MYSQL 5.6后row格式的binlog格式以及和事物有关的event,按照官方的说法
binlog的格式经历了几个阶段
v1:mysql 3.23
v3:mysql 4.0.2 到 4.1
v4:mysql 5.0以上
v2版本只是短暂的存在过,当然我们要解析当然是v4版本的binlog
因为要看是5.6以上的binlog
关于多字节的数字显示,一般使用 Little-endian模式,做到和OS系统无关,除非刻意说明
关于Little-endian参考:
http://blog.itpub.net/7728585/viewspace-2124159/
三、binlog的魔法数
关于MYSQL BINLOG的作用就不做过多的解析了,在binlog中存储的是一种称之为event的条目,
它们以二进制的格式存储,平时我们使用的mysqlbinlog工具也就是对这种二进制格式的文件
进行解析,得到直观的输出。这里不用mysqlbinlog而改为直接看二进制文件,当然我会对比
MYSQLBINLOG的输出和二进制解析的过程
每一个binlog文件都有4字节的魔法数,其值固定为
[root@testmy mysqld.1]# hexdump -Cv test.000005
可以看到
fe 62 69 6e .bin
四、binlog event的总体构架
一个event包括了
event header
event data
其中event data又分为
fixed data(posted header)
variable data
event header:全部的event统一固定的格式
fixed data(posted header):每一类event固定
variable data:就是可以变化实际值了
关于event的类型比较多详细参考末尾源码的截取
五、本系列文章要讨论的event
而这里我们只要讨论5.6,5.7中和row binlog格式和innodb
联系比较紧密的几种event如下:
query_log_event/QUERY_EVENT typecode=02
Format_description_log_event/FORMAT_DESCRIPTION_EVENT typecode=15
Xid_log_event/XID_EVENT typecode=16
Table_map_log_event/TABLE_MAP_EVENT typecode=19
Write_rows_log_event/WRITE_ROW_EVENT typecode=30
Update_rows_log_event/UPDATE_ROW_EVENT typecode=31
Delele_rows_log_event/DELETE_ROW_EVENT typecode=32
因为这些语句是一个事物必须经历的,而Format_description_log_event是一个最重要的
说明性的event
六、通用头文件(event header)解析
下面先解释一下通用的19个字节。
每一个event有一个固定的头信息叫做event header:
event header
timestamp 0:4
type_code 4:1
server_id 5:4
event_length 9:4
next_position 13:4
flags 17:2
timestamp:固定4字节展示是新纪元(epoch time)以来的秒数
type_code:固定1字节event事件的编码,在源码中是一个enum类型负载最后源码处
server_id:固定4字节就是 show variables like '%server_id';出来的值
event_length:固定4字节整个event的长度,包含固定和非固定长度
next_position:固定4字节下一个event的开始位置(2^32为4G)
flags:固定2字节 event flags
LOG_EVENT_BINLOG_IN_USE_F 0x1 这个flags表示是否binlog正确的关闭了,这个标示只出现在Format_description_log_event中
LOG_EVENT_THREAD_SPECIFIC_F 0x4 是否查询基于了临时表,如果基于了临时表MYSQLBINLOG必须设置 @@PSEUDO_THREAD_ID=xx
LOG_EVENT_SUPPRESS_USE_F 0x8 和--binlog-do-db 、 --replicated-do-db有关
其他还有很多
LOG_EVENT_ARTIFICIAL_F 0x20 LOG_EVENT_RELAY_LOG_F 0x40 LOG_EVENT_IGNORABLE_F 0x80 LOG_EVENT_NO_FILTER_F 0x100 。。。
可以自行参考log_event.h源码头文件中的详细解释
七、packed interger
在binlog中部分数字使用这种方式显示,在后面的解析中会提到
按照文档和源码中的说明
如果第一个字节为0-250及0X0-0XFA那么这个字节就是实际显示的数字值
源码的:
if (length < (ulonglong) LL(251))
{
*packet=(uchar) length;
return packet+1;
}
如果第一个字节为252及0XFC那么后面的2个字节的值为0XFB-0XFFFF
源码的:
if (length < (ulonglong) LL(65536))
{
*packet++=252;
int2store(packet,(uint) length);
return packet+2;
}
如果第一个字节为253及0XFD那么后面的3个字节的值为0XFFFF-0XFFFFFF
源码的:
if (length < (ulonglong) LL(16777216))
{
*packet++=253;
int3store(packet,(ulong) length);
return packet+3;
}
如果第一个字节为254及0XFE那么后面的8个字节的值为0XFFFFFF-0XFFFFFFFFFFFFFFFF
*packet++=254;
int8store(packet,length);
可以自行参考源码接口,函数返回值为一个下一个位置的指针
uchar *net_store_length(uchar *packet, ulonglong length)
点击(此处)折叠或打开
enum Log_event_type
{
/**
Every time you update this enum (when you add a type), you have to
fix Format_description_event::Format_description_event().
*/
UNKNOWN_EVENT= 0,
START_EVENT_V3= 1,
QUERY_EVENT= 2,
STOP_EVENT= 3,
ROTATE_EVENT= 4,
INTVAR_EVENT= 5,
LOAD_EVENT= 6,
SLAVE_EVENT= 7,
CREATE_FILE_EVENT= 8,
APPEND_BLOCK_EVENT= 9,
EXEC_LOAD_EVENT= 10,
DELETE_FILE_EVENT= 11,
/**
NEW_LOAD_EVENT is like LOAD_EVENT except that it has a longer
sql_ex, allowing multibyte TERMINATED BY etc; both types share the
same class (Load_event)
*/
NEW_LOAD_EVENT= 12,
RAND_EVENT= 13,
USER_VAR_EVENT= 14,
FORMAT_DESCRIPTION_EVENT= 15,
XID_EVENT= 16,
BEGIN_LOAD_QUERY_EVENT= 17,
EXECUTE_LOAD_QUERY_EVENT= 18,
TABLE_MAP_EVENT = 19,
/**
The PRE_GA event numbers were used for 5.1.0 to 5.1.15 and are
therefore obsolete.
*/
PRE_GA_WRITE_ROWS_EVENT = 20,
PRE_GA_UPDATE_ROWS_EVENT = 21,
PRE_GA_DELETE_ROWS_EVENT = 22,
/**
The V1 event numbers are used from 5.1.16 until mysql-trunk-xx
*/
WRITE_ROWS_EVENT_V1 = 23,
UPDATE_ROWS_EVENT_V1 = 24,
DELETE_ROWS_EVENT_V1 = 25,
/**
Something out of the ordinary happened on the master
*/
INCIDENT_EVENT= 26,
/**
Heartbeat event to be send by master at its idle time
to ensure master's online status to slave
*/
HEARTBEAT_LOG_EVENT= 27,
/**
In some situations, it is necessary to send over ignorable
data to the slave: data that a slave can handle in case there
is code for handling it, but which can be ignored if it is not
recognized.
*/
IGNORABLE_LOG_EVENT= 28,
ROWS_QUERY_LOG_EVENT= 29,
/** Version 2 of the Row events */
WRITE_ROWS_EVENT = 30,
UPDATE_ROWS_EVENT = 31,
DELETE_ROWS_EVENT = 32,
GTID_LOG_EVENT= 33,
ANONYMOUS_GTID_LOG_EVENT= 34,
PREVIOUS_GTIDS_LOG_EVENT= 35,
TRANSACTION_CONTEXT_EVENT= 36,
VIEW_CHANGE_EVENT= 37,
/* Prepared XA transaction terminal event similar to Xid */
XA_PREPARE_LOG_EVENT= 38,
/**
Add new events here - right above this
Existing events (except ENUM_END_EVENT) should never change their numbers
*/
ENUM_END_EVENT /* end marker */
};
intvar mysql_mysql binlog格式解析(一)相关推荐
- mysql binlog c++_MySQL binlog的格式解析
我搜集到了一些资料,对理解代码比较有帮助. 在头文件中binlog_event.h中,有描述 class Log_event_header class Log_event_footer 参见[Myst ...
- mysql格式分隔符row_MySQLRow格式Binlog的解析(1)
用MySQL 行格式的复制的Slave经常会遇到复制出错1062和1032 错误,一般是镜像异常宕机导致主从复制数据不一致所致,但是有些库本身很大,重建成本很大,并且这些库的数据一致性用户可能都不是太 ...
- binlog二进制文件解析
本文主要介绍MySQL的binlog二进制文件的解析,目的是更好的了解binlog文件的构成并做相应的二次开发,并帮助对主从复制机制有更多理解. 以下内容基于row的日志格式.操作系统redhat7, ...
- 技术分享 | binlog 实用解析工具 my2sql
作者:赵黎明 爱可生 MySQL DBA 团队成员,Oracle 10g OCM,MySQL 5.7 OCP,擅长数据库性能问题诊断.事务与锁问题的分析等,负责处理客户 MySQL 及我司自研 DMP ...
- mysql error 1837_MySQL复制错误1837的相关缺陷一例——insert delay在GTID下异常binlog格式...
本文作者:鲁越 导语:insert delay在GTID下异常binlog格式 一.问题描述 1) 客户反馈,两个RO同时复制异常,程序读不到最新的数据. 2) 上线看了一下报错信息.数据库版本5.6 ...
- mysql xid_MySQL Binlog 文件格式解析(XID_EVENT)
1. XID_EVENT 是什么? MySQL Binlog 文件由 event 组成,event 有不同的类型,本文介绍的 XID_EVENT 表示一个事务的提交操作. 举个例子,执行一条事务,然后 ...
- 转:YUV RGB 常见视频格式解析
转: http://www.cnblogs.com/qinjunni/archive/2012/02/23/2364446.html YUV RGB 常见视频格式解析 I420是YUV格式的一种,而Y ...
- mysql修改binlog格式_mysql binlog格式...
项目采用了spring的事务机制,在发布时遇到了问题.后台报了异常. Binary logging not possible. Message: Transaction level 'READ-COM ...
- 【Android RTMP】音频数据采集编码 ( AAC 音频格式解析 | FLV 音频数据标签解析 | AAC 音频数据标签头 | 音频解码配置信息 )
文章目录 安卓直播推流专栏博客总结 一. AAC 音频格式解析 二. FLV 音频数据标签解析 1. 分析 FLV 格式中的 AAC 音频格式数据 2. AAC 音频特殊配置 3. AAC 音频数据标 ...
最新文章
- left join左表百万数据查询慢_Spark SQL 之 Join 实现
- python与建筑设计_建筑学是学c语言好还是Python好?
- 201521123122 《java程序设计》第十三周学习总结
- “面试不败计划”:面试题基础一
- 全球及中国汽车物流行业未来发展方向与投资机遇研究报告2022版
- 【Python】直接赋值、浅拷贝和深度拷贝解析
- linux不能识别 符号,在linux中文件中^M符号的问题以及中文识别问题
- jvm fastdebug
- java final内存机制_Java中的内存处理机制和final、static、final static总结
- linux工作笔记-linux之间文件传输图形界面工具gftp
- windows安装Linux卡logo,Dell xps 15 windows ubuntu16.04 UEFI 双系统安装 卡在logo界面 卡***问题解决...
- HDOJ 5184 Brackets 卡特兰数扩展
- fastdfs 集群配置
- Flutter Animation 3D仿真书本翻页动画效果
- android安装到内存卡,android手机怎么把软件安装到内存卡里
- 海外社交媒体最佳图片尺寸
- 如何稳步实现互联网流量变现?
- 阿里云客户案例——周大福珠宝集团
- 《Python cookbook》 “定义一个属性可由用户修改的装饰器” 笔记
- 不要这样学习C语言,这是个坑!
热门文章
- kafka启动后会挂掉的原因
- 为什么MySQL索引要使用 B+树,而不是其它树形结构?
- leetcode 62, 63, 980. Unique Paths I, II, III | 62, 63, 980. 不同路径 I, II, III(暴力递归->傻缓存->动态规划)
- 【Java类加载机制】深入加载器
- java中functional interface的分类和使用
- linux perl 安装目录,肿么查看linux是否安装了perl
- Spring系列之bean的使用
- Spring手动回滚事务
- 容器学习 之 管理multi-host(十八)
- Effective Java之抛出与抽象相应的异常(六十一)