关于吴 炳锡

数据库架构师 熟悉MySQL架构设计及数据库架构优化。 丰富的MySQL优化及高可用架构经验。

[20150924]公开分享-优秀MySQL DBA进化之路

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.
分享主题: 优秀MySQL DBA进化之路
分享时间: 2015年9月24日 20:30-22:00
分享方式: 加入QQ群: 373900864 或 125572178,并通过YY频道: 86142750 语音直播(请提前下载YY语音客户端)

分享嘉宾: 吴炳锡
北京新媒传信数据库架构师,专注于后端高性能服务及DB存储治理。
中国CMUG核心组织者,MySQL布道者。
熟悉MySQL高可用方案,丰富的大型系统后端存储规划设计,
熟悉多机房架构设计及运维,丰富的自动化平台开发及实践。
个人博客:http://wubx.net

内容简介:
分享者结合自已10年+的MySQL DBA工作相关工作, 通过中高级DBA工作中的工内容,给大家全面展示一下MySQL DBA工作的职责及技能需求,给自已想成为MySQL DBA的人员一个主线,同时给大家指出学习MySQL DBA技能中的注意事项。
内容大纲:
1. 为什么要成为MySQL DBA
2. 如何成为MySQL DBA
3. MySQL DBA的工作内容
4. 优秀的MySQl DBA怎么练成
5. MySQL DBA路在何方

备注:

如果你的群里想进行直播,请联系我QQ: 82565387

泰岳教育-python周末班开课

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.
北京神州泰岳教育科技有限公司(以下简称:泰岳教育)隶属于上市公司神州泰岳(股票代码300002),定位于以在线方式或实训基地模式为在校大学生和职业人士提供互联网+行业的职业能力培训服务,致力于打造国内首家互联网+职业技能的专业学习平台。因为公司转型,我们内部也有了一次新的机会,所以我和几个同事,一块拉起一个内部叫: 泰岳学院 组织: 定位几个方向: 数据库, 大数据, 测试 三个方向。 每个方向展开后还会有一些小课,这里不细说了。做为创业项目,我也需要历练一下。所以准备先开一期周末班试运行一下,在次宣传一下:

泰岳学院 python周末班开课了

现在互联网时代,传统运维面临极大的挑战,也是小鲜肉们经常去搞的Python,Ruby,Golang盛行的运维年代,所以

  • 如果你是MySQL DBA请你来提高一下,给自已添加一项新技能,让自已能在重复的劳动解放出来,去思考,去进步
  • 如果你是SA请你来提高一下, 给自已添加一项新技能,可以有能力开发一个管理平台
  • 如果你想成为一个专职的Python程序员,这里更是你应该来的地方,大师级开发人员带你感受Python之美

计划10月18日开课
开课周期: 10月初到12月初,每周日全天实体共计10天教学
授课老师: 业界知名某云RDS核心开发人员
大纲: http://pan.baidu.com/s/12ip1k
上课地点: 北京地铁5号钱北苑路北站 向北100米 泰岳大厦19层
第一期是VIP小班优惠进行中,最多15人,现在仅剩9个名额 (以交费为准)
有兴趣私聊吴老师,QQ: 82565387, Tel: 13501245755
更多详情直接和我联系吧。 第一期做的信任,做的是口碑。 相互加油:)

 

BTW:

第二期MySQL DBA班还有三个名额 ,开课时间: 10月17日。

第一期学员就业有去京东, 滴滴打车, 支付宝,魅族等大公司。 欢迎咨询。

MySQL Binlog Server

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

MySQL Binlog Server:是利用某个工具,把线上活跃的库的日志拉取到本地进行备份。在MySQL 5.6以后,可以利用mysqlbinlog这个命令去把远程机器的日志备份到本地目录,从而达到增量或是日志安全方面的备份。

做好MySQL日志的备份,是数据安全的一个重要保证。以前通过写程序来实现,从MySQL 5.6出现以后,DBA同步有福了,不用写程序了。
下面说一下binlog Server怎么构建。
利用mysql 5.6的mysqlbinlog命令,可以把远程的binlog完全镜象一份放到本地,方法如下:

/usr/local/mysql/bin/mysqlbinlog -R --raw --host=192.168.11.100 --user='repl' --password='repl4slave' --stop-never mysql-bin.000001&

解释一下:
-R –read-from-remote-server 表示从远程机器上读取binlog,要确保远程mysql存储,需要提供–host, –user, –password参数
–raw 以binlog格式存储日志,方便后期使用
–stop-never 一直连接到远程的server上读取日志,直接到远程的server关闭后才会退出。或是被pkill掉
mysql-bin.0000001 这个日志名表示从那个日志开始读取

如果需要启动多个binlog server,需要给binlog server指定server-id(默认是65535),可以利用 –stop-never-slave-server-id变更

启动一个server-id为1的binlog server:

/usr/local/mysql/bin/mysqlbinlog -R --raw --host=192.168.11.100 --user='repl' --password='repl4slave' --stop-never --stop-never-slave-server-id=1 mysql-bin.000003&

启动一个server-id为2的binlog server:

/usr/local/mysql/bin/mysqlbinlog -R --raw --host=192.168.11.100 --user='repl' --password='repl4slave' --stop-never --stop-never-slave-server-id=2 mysql-bin.000003&

思考:
这种binlog server怎么关闭才算安全呢?

我的现状说明-MySQL DBA周末班招生

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

我在现就职于神州泰岳集团下子公司: 北京新媒传信, 目前我们公司在教育方向进行大量的投入,创建了:泰岳教育: http://www.ultraedu.com.cn/   套用官方的话介绍一下:

北京神州泰岳教育科技有限公司(以下简称:泰岳教育)隶属于上市公司神州泰岳(股票代码300002),定位于以在线方式或实训基地模式为在校大学生和职业人士提供互联网+行业的职业能力培训服务,致力于打造国内首家互联网+职业技能的专业学习平台。

因为公司转型,我们内部也有了一次新的机会,所以我和几个同事,一块拉起一个内部叫: 泰岳学院 组织: 定位几个方向: 数据库, 大数据, 测试 三个方向。 每个方向展开后还会有一些小课,这里不细说了。

做为创业项目,我也需要历练一下。所以准备先开一期周末班试运行一下,在次宣传一下:

泰岳学院 北京MySQL DBA周末实体班开班了

  • 计划6月6日开课
  • 开课周期: 6月到10月初,每周六全天实体,周四晚上在线交流
  • 授课老师: 吴炳锡 blog: http://www.mysqlsupport.cn/   http://wubx.net
  • 大纲: http://pan.baidu.com/s/12ip1k
  • 上课地点: 北京地铁5号钱北苑路北站 向北100米 泰岳大厦19层
  • 第一期是VIP小班优惠进行中,最多15人,现在仅剩7个名额 (以交费为准)
  • 有兴趣私聊吴老师,QQ: 82565387, Tel: 13501245755

更多详情直接和我联系吧。 第一期做的信任,做的是口碑。 相互加油:)

目前已经有多家互联网公司向我预定毕业的学生,如果你想提升一下,或是想找一个进行互联网的机会,就行动吧。 以后更多想法,等我一期运行起来在公布。

备注:

 

 20150524   感谢各位支持,第一期VIP小班招生完毕。第二期估计到9月开始招生 期待大家的加入。

 

美的招聘-MySQL DBA

美的现在也想走开源路线,所以大量需要开源相关的人才,MySQL DBA也成了招聘中的重中之重。

该公司强烈推荐,二线城市,一线的待遇,舒适的生活:) 

具体信息如下:

高级MySQL数据库架构师
职位描述:
1.负责数据库架构规划、设计及技术指导;
2.负责关键技术研究及实现,提供满足产品设计规划的数据库领域设计方案;
3.及时解决项目开发或产品研发中的技术难题,对设计平台的最终性能和稳定性负责;
4.负责mysql数据库技术规范建设;
5.培训软件工程师,指导复杂模块的开发;

职位要求:
1.具备5年以上大型Mysql数据库开发设计经验;
2.具备MySQL,ORACLE,SQLserver等数据库的一种或多种的运行机制和体系架构经验;
3.精通sql语句,熟悉数据库的备份恢复及数据迁移等策略,熟练为数据库打补丁,版本升级等;
4.熟悉分布式数据库设计和建设方案,海量数据库分库分表策略以及高并发OLTP、OLAP系统的设计和维护;
5.精通数据库产品性能分析和测试,对数据库的优化,存储性能有较深的研究和操作经验;
6.精通Linux系统,熟练各种命令;
7.了解mogondB等NOSQL、的数据存储产品,熟悉不同类型和数据库的底层运行原理和优缺点;
8.了解Hadoop集群的搭建、配置与管理,对Hadoop源码有深入研究,有对Hadoop优化方面的经验优先;
9.善于处理数据库运行故障和安全加固;
10.熟悉建立数据库仓库及有数据分析与挖掘基础优先。

高级MySQL数据库管理工程师
职位描述:
1.负责Mysql数据库日常运维及故障解决,备份恢复维护;
2.负责Mysql数据库性能调优及数据安全,并负责补丁升级;
3.负责MySQL数据库集群、分库/分表和高可用方案实施等;
4.处理日常事务性数据库操作,提供业务和公司决策支持;
5.协助开发完成数据库表的设计及SQL调优;

职位要求:
1.三年以上DBA相关管理经验,具备大型互联网高并发下Mysql数据库管理经验;
2.精通/熟悉MySQL数据库的运行机制和体系架构,深入理解InnoDB引擎,熟悉MySQL数据库应用运行体系及高可用解决方案;
3.精通/熟悉Mysql数据库的管理,具备批量化数据库运维经验;
4.精通/熟悉MySQL数据库性能调优,SQL优化,服务器优化;
5.熟悉Linux操作系统管理与维护;
6.熟悉shell/perl/python等脚本编写;
7.有MongoDB、Redis、HBase等维护经验优先;
高级MySQL数据库开发工程师
职位描述:
1.负责数据库设计及代码开发;
2.配合产品部门制定数据库技术方案,分库分表策略,数据迁移方案;
3.参与数据库查询分析和性能优化,参与制定SQL编写规范、代码开发和SQL审查;

职位要求:
1.三年以上数据库开发经验;
2.精通数据库基本原理,熟悉SQL语言,精通掌握存储过程等技术;
3.熟悉数据仓库的ETL开发和主题数据建模;
4.熟悉Linux操作系统,具有Shell, C或Java编程经验;
5.熟悉基于MySQL的大规模分布式系统,具有基于MySQL的大规模分布式系统设计/开发经验者优先;
6.熟悉MySQL内核,具有分析其代码实现和具有修改、编写经验者优先;

工作地点:广东顺德
简历邮箱:pirate@linuxboy.cn
待遇从优,欢迎各方人才加入!!!

2014.12.11 MySQL技术分享之:《深入浅出MySQL GTID》

2014.12.11 MySQL技术分享之:《深入浅出MySQL GTID》

分享时间:2014年12月11日20:30

分享嘉宾:冯浩|ISADBA

现chinaunix.net MySQL版主,原51CTO.com Linux版主

6年互联网工作经验,关注数据库,自动化运维,电子商务.

BLOG:http://isadba.com

新浪微薄:@ISADBA

在如今的互联网行业里,数据库可用性、扩展性、性能都非常重要。

MySQL数据库很多的高可用及scale out方案都是基于replication实现的,相对其他方案整体性价比会高出很多。

从MySQL 5.6.2新增GTID特性,利用GTID以让我们更加容易的管理MySQL复制,并有效提高数据库一致性。

这次的分享主要针对MySQL GTID展开,主要的分享内容如下:

1、MySQL集群方案

2、MySQL Classic Replication

3、MySQL GTID Replication

4、Oracle MySQL GTID

5、MariaDB GTID

6、Oracle MySQL GTID VS MariaDB GTID

通过这次分享,大家可以GET到如下技能:

1、GTID和原来的复制有什么区别.

2、如何从原来的复制切换到GTID复制.

3、GTID复制的使用限制.

4、选择那个数据库版本或者分支开始使用GTID复制.

 

建议听众:

DBA,SA、程序员,架构师等MySQL相关从业人员

感兴趣的同学请提前加入QQ群:125572178,更多精彩分享等着你 :)

[技术分享] MySQL线上SQL捕获及分析

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

分享题目:MySQL线上SQL捕获及分析

分享者: 吴炳锡

时间: 2014年11月21日, 20:30-10:30
分享方式: 在线分享,利用QQ+YY,参加同学,提前加入QQ群:373900864 (暗号: 群主是帅哥)

该PPT是在2014 Oracle技术嘉年华上的一个分享,分享后,很多同学在QQ找我聊,怎么做线上SQL的分析之类。当然也有很多同学没能参加,我就是借着网络在此做一次分享,利用网络和大家做一个交流。分享的方式: QQ+YY (没有YY的同学需要注册一个)

优化是DBA或是架构师们在不断追求的方向,也是大家热忠追求的技术,如果说优化是技术里面的屠龙技术,要想去屠龙很重要的技术是要学会寻龙,在分本享中,通过线上SQL捕获,和大家一块讨论一下如何寻找SQL优化中的大龙。

分享内容:

  • 线上捕获SQL方法
  • 基于tcpdump线上SQL抓取
  • 基于查询日志记录
  • 基于慢日志记录全量日志
  • 捕获的SQL分析方法
  • 线上SQL抓取及分析平台化实现

感兴趣的同学请提前加入QQ群: 373900864 更多精彩分享等着你。

redis-oom-command-not-allowed报错

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

OOM command not allowed when used memory > ‘maxmemory’ 报错排查

grep “OOM command not allowed when used memory > ‘maxmemory'” * -r
src/redis.c: “-OOM command not allowed when used memory > ‘maxmemory’.\r\n”));

查看src/redis.c

    shared.oomerr = createObject(REDIS_STRING,sdsnew(
    "-OOM command not allowed when used memory > 'maxmemory'.\r\n"));

    。。。

/* Handle the maxmemory directive.
*
* First we try to free some memory if possible (if there are volatile
* keys in the dataset). If there are not the only thing we can do
* is returning an error. */
if (server.maxmemory) {
 int retval = freeMemoryIfNeeded();
 if ((c->cmd->flags & REDIS_CMD_DENYOOM) && retval == REDIS_ERR) {
     flagTransaction(c);
    addReply(c, shared.oomerr);
    return REDIS_OK;
}
}

从代码确认报这个错,大概是内存达到最大限时不能释放出来内存报的错。

做一个简单的验证:

配置一个10M大小的Redis,利用一个python程序往里面写数据,很快得到报错:

#python t_redis.py 
Traceback (most recent call last):
  File "t_redis.py", line 21, in <module>
 start()
File "t_redis.py", line 15, in start
  s = r.set(key, v1)
File "/usr/lib/python2.6/site-packages/redis/client.py", line 647, in set
return self.execute_command('SET', name, value)
File "/usr/lib/python2.6/site-packages/redis/client.py", line 330, in execute_command
**options
File "/usr/lib/python2.6/site-packages/redis/client.py", line 312, in _execute_command
return self.parse_response(command_name, **options)
File "/usr/lib/python2.6/site-packages/redis/client.py", line 390, in parse_response
    response = self._parse_response(command_name, catch_errors)
File "/usr/lib/python2.6/site-packages/redis/client.py", line 349, in _parse_response
 raise ResponseError(response)
redis.exceptions.ResponseError: OOM command not allowed when used memory > 'maxmemory'.

结论:

  1. Redis运行中监控内存的使用情况.
  2. 如果只做缓存使用,需要配置上lru策略,如
     maxmemory-policy allkeys-lru
     maxmemory-samples 5
    

    如果做持久化存储说明,内存也不够用了。需要考虑增加内存。

  3. 故障现场要看一下Redis的info输出,看看内存配是否达到了上限。

varchar和text说不清的那些事

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.

最近有几个同学问我varchar和text有啥别吗,这个问题,以前说真的也没太多的整理,以前遇到text在设计中就是尽可能的拆到另一个表中,保持主表尽量的瘦小,可以让innodb bp缓存更多的数据。

今天借次机会系统整理一下,主要从存储上,最大值,默认值几个方面进行比较。

BTW: 从ISO SQL:2003上讲VARCHAR是一个标准型,但TEXT不是(包括tinytext).varchar在MySQL 5.0.3之前只支持0-255byte, 在5.0.3之后才支持到0-65535byte.

从存储上讲:

- text 是要要进overflow存储。 也是对于text字段,不会和行数据存在一起。但原则上不会全部overflow ,
会有768字节和原始的行存储在一块,多于768的行会存在和行相同的Page或是其它Page上。

- varchar 在MySQL内部属于从blob发展出来的一个结构,在早期版本中innobase中,也是768字节以后进行overfolw存储。

- 对于Innodb-plugin后: 对于变长字段处理都是20Byte后进行overflow存储
(在新的row_format下:dynimic compress)

说完存储后,说一下使用这些大的变长字段的缺点:

- 在Innobase中,变长字段,是尽可能的存储到一个Page里,这样,如果使用到这些大的变长字段,会造成一个Page里能容纳的行
数很少,在查询时,虽然没查询这些大的字段,但也会加载到innodb buffer pool中,等于浪费的内存。
(buffer pool 的缓存是按page为单位)(不在一个page了会增加随机的IO)

- 在innodb-plugin中为了减少这种大的变长字段对内存的浪费,引入了大于20个字节的,都进行overflow存储,
而且希望不要存到相同的page中,为了增加一个page里能存储更多的行,提高buffer pool的利用率。 这也要求我们,
如果不是特别需要就不要读取那些变长的字段。

那问题来了? 为什么varchar(255+)存储上和text很相似了,但为什么还要有varchar, mediumtext, text这些类型?
(从存储上来讲大于255的varchar可以说是转换成了text.这也是为什么varchar大于65535了会转成mediumtext)

我理解:这块是一方面的兼容,另一方面在非空的默认值上varchar和text有区别。从整体上看功能上还是差别的。

这里还涉及到字段额外开销的:

- varchar 小于255byte  1byte overhead
- varchar 大于255byte  2byte overhead

- tinytext 0-255 1 byte overhead
- text 0-65535 byte 2 byte overhead
- mediumtext 0-16M  3 byte overhead

- longtext 0-4Gb 4byte overhead

备注 overhead是指需要几个字节用于记录该字段的实际长度。

从处理形态上来讲varchar 大于768字节后,实质上存储和text差别不是太大了。 基本认为是一样的。
另外从8000byte这个点说明一下: 对于varcahr, text如果行不超过8000byte(大约的数,innodb data page的一半) ,overflow不会存到别的page中。基于上面的特性可以总结为text只是一个MySQL扩展出来的特殊语法有兼容的感觉。

默认值问题:

- 对于text字段,MySQL不允许有默认值。
- varchar允许有默认值

总结:

根据存储的实现: 可以考虑用varchar替代tinytext
如果需要非空的默认值,就必须使用varchar
如果存储的数据大于64K,就必须使用到mediumtext , longtext
varchar(255+)和text在存储机制是一样的

需要特别注意varchar(255)不只是255byte ,实质上有可能占用的更多。

特别注意,varchar大字段一样的会降低性能,所以在设计中还是一个原则大字段要拆出去,主表还是要尽量的瘦小

源码中类型:

+--Field_str (abstract)
 |  +--Field_longstr
 |  |  +--Field_string
 |  |  +--Field_varstring
 |  |  +--Field_blob
 |  |     +--Field_geom
 |  |
 |  +--Field_null
 |  +--Field_enum
 |     +--Field_set

(末完待续,也希望大家一块讨论一下)

参考:
http://yoshinorimatsunobu.blogspot.com/2010/11/handling-long-textsblobs-in-innodb-1-to.html

MySQL: TEXT vs. VARCHAR Performance


http://www.pythian.com/blog/text-vs-varchar/

 

测试SQL及方法

 

create table tb_01(
c1 varchar(255),
c2 varchar(255),
c3 varchar(255),
c4 varchar(255),
c5 varchar(255),
c6 varchar(255),
c7 varchar(255),
c8 varchar(255),
c9 varchar(255),
c10 varchar(255),
c11 varchar(255)
)engine=Innodb;

insert into tb_01(c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11) values(repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255));
ERROR 1118 (42000): Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.

(testing)root@localhost [wubx]> set global innodb_file_format=BARRACUDA;
Query OK, 0 rows affected (0.00 sec)

(testing)root@localhost [wubx]> alter table tb_01 row_format=dynamic;
Query OK, 0 rows affected (0.19 sec)
Records: 0  Duplicates: 0  Warnings: 0

(testing)root@localhost [wubx]> insert into tb_01(c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11) values(repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255));
Query OK, 1 row affected (0.00 sec)


set global innodb_file_format=Antelope;
create table tb_02(
c1 varchar(2000),
c2 varchar(2000),
c3 varchar(2000),
c4 varchar(2000),
c5 varchar(2000),
c6 varchar(2000),
c7 varchar(2000),
c8 varchar(2000)
)engine=Innodb;

insert into tb_02(c1, c2, c3,c4,c5,c6,c7,c8) values(repeat('吴',2000),repeat('吴',2000),repeat('吴',2000),repeat('吴',2000),repeat('吴',2000),repeat('吴',2000),repeat('吴',2000),repeat('吴',2000) );


create table tb_03(
c1 text,
c2 text,
c3 text,
c4 text,
c5 text,
c6 text,
c7 text,
c8 text,
c9 text,
c10 text,
c11 text
)engine=Innodb;
insert into tb_03(c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11) values(repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255));

(testing)root@localhost [wubx]> insert into tb_03(c1,c2,c3,c4,c5,c6,c7,c8,c9,c10,c11) values(repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255),repeat('吴',255));
ERROR 1118 (42000): Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.

set global innodb_file_format=BARRACUDA;
alter table tb_03 row_format=dynamic;

MySQL 二进制日志格式基础(一)

作者:吴炳锡 来源:http://wubx.net/ 联系方式: wubingxi#163.com 转载请注明作/译者和出处,并且不能用于商业用途,违者必究.
MySQL二制进日志用于记录数据库的变更记录,这里从结构上讨论一下日志的格式。

每个日志都包含4个字节的magic number 和event的描述包

  1. 日志有前四个字节是magic number: oxfe ox62 0x69 0x6e = 0xfe ‘b”i”n’ 转成整数:1852400382  用处就是读4个字节对比不是这个数,说明就不是二进制日志,就不用处理了。
      log_event.sh中可以查到
      /* 4 bytes which all binlogs should begin with */
         #define BINLOG_MAGIC        "\xfe\x62\x69\x6e"
    
  2. 每个event的header大概如下:
     - 每个event中包含: event的类型,什么时间,由哪版本的MySQL产生的
     - 从header头能找到该event的大小及一些变更信息
    
  3. 第一个event称为:format descriptor event(Event描述结构:FDE) 用于说明日志的格式
  4. 其它event就是依赖于描述结构不同,用不同的结构记录数据
  5. 最后一个event是: 日志切换事件(log-rotation event)用于指点定下个日志的文件名

每个event的结构大概如下:

+===================+
| event header      |
+===================+
| event data        |
+===================+

现在大多使用的V4结构,从MySQL 5.0起,具体如下:

+=====================================+
| event  | timestamp         0 : 4    |
| header +----------------------------+
|        | type_code         4 : 1    |
|        +----------------------------+
|        | server_id         5 : 4    |
|        +----------------------------+
|        | event_length      9 : 4    |
|        +----------------------------+
|        | next_position    13 : 4    |
|        +----------------------------+
|        | flags            17 : 2    |
|        +----------------------------+
|        | extra_headers    19 : x-19 |
+=====================================+
| event  | fixed part        x : y    |
| data   +----------------------------+
|        | variable part              |
+=====================================+

第一个event是FDE结构没有extra_headers部分,所以固定为19个字节。

FDE的event_data中定长部分为:

  • 2字节的的日志格式版本,从MySQL 5.0后都是4
  • 50字节 用于记录MySQL的版本号 如:5.6.16-64.2-rel64.2-log 不够50字节用0x00填充
  • 4字节 日志产生的时间
  • 1字节 header长度。一般是19,如果大于19,则下面的event都有extra_header字段
    对于FDE变长部分一般为空

其它Event计算

  • header length = x byte
  • data length = (event_lenth -x )byte
  • 数据区里定长部分长度
      fixed_part = y byte
      variable_part = (event_length - (x+y)) byte
    

如果给定的X不是19,则存extra_header里面有内存
Y依赖于event_type有不同的大小,需要参考不同的event进行特别处理
参考:http://dev.mysql.com/doc/internals/en/event-data-for-specific-event-types.html