Binglog格式与主从复制——Mysql

 

一、Mysql Binlog协议格式

一个Binlog格式文件，前四个字节是：0xfe62696e；对应0xfe、’b’、’i’、’n’，这是雷打不动的公理。

后面是一系列的Binlog Event，每个Event包括Header与Data两部分。Mysql这帮人跟我们一样俗，定义一个消息先定个头、再定一个消息体；看来也没有更好的方法了。

1、Header部分固定长度19字节（比较老的mysql可能不是，低于mysql5.0），结构如下：

 

代表的意义分别是：

Timestamp： Sql执行时间戳

EventType： Event类型(1字节，大约有二三十种类型吧)

ServerID： 产生binlog的ServerID

EventSize： Event的大小(header与data两部分)

NextEventPos： 下一个Event的偏移量(对应Binlog文件的偏移量)

Flags： 标志信息。

2、Data部分是针对一个Event的具体变更信息，这一部分比较复杂。

二、主从复制各种文件偏移量说明

1、 > show master status

 

show master status得到的是Mysql实例的Binlog文件名、以及偏移量，例如上面的例子这台mysql实例正在写的Binlog文件是master-bin.000018，文件大小已经达到了6998

2、> show slave status

 

如果开启了主从同步，在从机上面执行show slave status，会得到类似上面信息，重点关注红色部分。

a、Master_Log_File、Read_Master_Log_Pos：从机的IO线程接收主机的Binlog推送位置。

b、Relay_Log_File、Relay_Log_Pos：从机的SQL复制线程，正在执行的SQL语句对应本地的Relay log位置(从机接收主机的Binlog存储到本地称其为Relay log，跟主机上面的Binlog不一致，有修改，从上面的信息文件名、偏移量不一致就可以看出)。

c、Relay_Master_Log_File、Exec_Master_Log_Pos：从机SQL复制线程，正在执行的SQL语句对应主机Binlog的位置。

 

唾沫星子喷了一滩，你明白了没有？

再举个例子唠叨一下：一个女孩子对你bulabula......说了很多，你听进去了多少？你又理解了多少？你一时半会理解不了怎么办？你正在苦思冥想的时候突然想入非非了怎么办？

女孩子说了多少对应：show master status得到的[File:Position]

你听进去了多少对应：[Master_Log_File:Read_Master_Log_Pos]

你理解了多少对应：[Relay_Master_Log_File:Exec_Master_Log_Pos]

你一时理解不了总要先找个地方存一下吧？对应此处的Relay log

你在解码女孩子话的过程是：先听了存下来(Relay log)，再慢慢消化吸收；如果想入非非了回神的时候该从那儿继续解码：[Relay_Log_File:Relay_Log_Pos]

三、通过Binlog恢复数据

Binlog产生的目的天然就是这个应用，他就是干这事的，把这事干好是他的本能；所以这个比较简单 So easy ......，没啥好说的。

首先，使用mysqlbinlog命令指定文件名、偏移量，dump出指定偏移量往后的SQL文件；

然后，通过mysql命令使用上面得到的SQL文件恢复数据，This’s all.

 

四、通过Relay log恢复数据

这个小有点麻烦，请君搬个板凳，请我慢慢道来......

在一主多从的情况下面，Master挂掉了，如果提升一台Slave为主，剩下的Slave跟随新的主同步，基于文件名偏移量的同步方式，Mysql自身做不到，它表示套路太深，不玩了......；不过后来Google大神发明了神奇的GTID(Mysql5.6开始支持)。今天我们讨论的还是陈旧的文件名偏移量的同步方式(新事物的推广与普及是需要代价的)。

 

如果Master挂了，多台Slave可能状态不一致；我们设想如果先将其数据恢复成一致(用胸想想都是应该是恢复成跟数据相对最全的Slave一致)，然后随机提升一台为Master，剩余Slave都跟他同步就好了；看上去挺美好、挺简单的(多数领导也都是这么认为的，还好我厂的领导是英明的...)，核心问题是怎么恢复成一致？

 

你说美女老师讲课的内容学霸都有记笔记，我把我落下的、笔记上面没有的都抄过来就好了；痴人做梦，你以前都是跟随美女老师记笔记，突然让你去抄学霸的，你都不知道该从哪儿抄了？毕竟不是完全一样的。好在学霸就是学霸，学霸竟然把自己笔记的页码跟老师备课讲义页码对应关系都记录下来了；你是有老师备课讲义页码的，你拿着这个页码从学霸笔记的最后一页往前翻，一直翻呀翻，应该不用等到地老天荒的那一天，很快你就找到了相应的位置，Ok，就从此处奋力往前追吧...。多问一下为什么从后往前翻？聪明的你一定猜到了，往往你不会落下太多(事情往往都是一分定命运，你从此过上锄禾日当午的生活，学霸日日风花雪月)。

 

回归正题，Relay log也是一种Binlog，只是特殊一点；你可以认为它的每个Event有记录是从Master的那个文件名、偏移量对应的Event同步过来的。有了这个参照物一切问题都迎刃而解了。

 

Relay log会在文件中记录一个ROTATE_EVENT类型的Event，ROTATE_EVENT类型的Data中有两项内容：文件名、偏移量；意思就是说后面的这些Event事件是从Master的这个位置开始同步的。尽管有了这个信息还是不能一一确定两者之间的Event对应关系；因为Relay log还是会添加一些它自身的事件信息在里面。

还记的我们一开始说的Event事件的Header头部中有个NextEventPos字段吗？好家伙这个字段在Relay log中所表达的含义来了一个乾坤大挪移，它在Relay log中的意思是：此Event在Master的Binlog中下个Event的位置；意思就是说，同一个Event在Master的Binlog与Slave的Relay log中这个字段值是一样的。有了这层关联，再加上前面的文件名对应关系，就可以一一确定每个Event的对应关系了。找到了丢失数据的位置，恢复的过程同Binlog恢复数据。

 

附上两张截图,两张截图end_log_pos红框处对应的Event事件是同一个。

第一张截图是Slave的Relay log，对应文件名[relay-bin.000002]。

第二张截图是Master的Binlog，对应文件名是[master-bin.000018]这一点从Relay log的Rotate事件也可以看出来。

 

 

 （by:刘延允；2016-11）

转载注明出处：http://blog.csdn.net/gdutliuyun827