MySQL偏移量的一点分析

在搭建MySQL主从的时候，change master是一个关键，如果没有使用GTID的方式，就需要使用偏移量和指定的binlog，每次需要手工去抓取这些信息，感觉还是比较费力，而且偏移量对我们来说就是一个黑盒子，到底递增多少，我们也不知道，只是给我们一个结果，但是搭建了一些环境之后，我突然发现了一些“规律”，比如下面的语句。

CHANGE MASTER TO

MASTER_HOST='192.168.xxx.xxx.',

MASTER_USER='rpl_user1',

MASTER_PASSWORD='xxxx',

MASTER_PORT=24405,

MASTER_LOG_FILE='mysqlbin.000002',

MASTER_LOG_POS=154;

偏移量是154，当时觉得可能是巧合吧，也就没有在意，但是又配置了几套环境，发现指定的binlog偏移量都是154，我觉得这个问题蛮有意思，就做了些简单的测试。

我找了很多套环境，建立了主从复制关系，发现不同版本的这个偏移量都有些差别。

比如在Percona的一个指定版本中就是154，在官方版本中就是另外一个值，是否开启GTID使得这个偏移量也有很大的差别。怎么从这些信息中找到一个共性的东西呢。

我觉得偏移量就是一个类似步长的指标，对于MySQL中的操作都是通过event来触发，每个event的触发都有一个指定的步长，或者是一个指定范围的值。

比如在slave中show slave status的结果。

mysql> show slave statusG

*************************** 1. row ***************************

Slave_IO_State: Waiting for master to send event

Master_Host: 192.168.xx.xxx

Master_User: rpl_user1

Master_Port: 24402

Connect_Retry: 60

Master_Log_File: mysqlbin.000027

Read_Master_Log_Pos: 154

Relay_Log_File: slave-relay-bin.000009

Relay_Log_Pos: 356711893

Relay_Master_Log_File: mysqlbin.000024

Slave_IO_Running: Yes

Slave_SQL_Running: Yes

如此一来，我的分析就有了一些思路，在不同版本中，这个值可能是有一定的差别，那我就不用钻牛角尖在这个具体的值上了。在不同的版本，是否启用GTID等都会有一个不同的范围。

-----+----------------+-----------+-------------+---------------------------------------

Pos | Event_type | Server_id | End_log_pos | Info

-----+----------------+-----------+-------------+---------------------------------------

4 | Format_desc | 228048 | 123 | Server ver: 5.7.19-log, Binlog ver: 4

通过上面的例子可以看到，其实的偏移量是4，第一行的信息就是binlog日志的头部信息了，Percona 5.7.19的这个偏移量终止于123,如果是在5.5.19的官方版本，这个值是107。

那得到了这个信息，对我们处理问题有什么实际意义呢，目前来看是没有，我们指定偏移量还是得做基本的验证。

那我们换个角度。查看binary log的信息。

mysql> show binary logs;

+---------------+-----------+

| Log_name | File_size |

+---------------+-----------+

| binlog.000019 | 239621 |

| binlog.000020 | 249 |

| binlog.000021 | 3783715 |

| binlog.000022 | 16632 |

| binlog.000023 | 249 |

| binlog.000024 | 249 |

| binlog.000025 | 65965 |

| binlog.000026 | 270 |

| binlog.000027 | 230 |

+---------------+-----------+

可以看到日志的大小。

系统层面的日志情况如何呢。可以看到日志的大小不一，很可能是我们做了手工做了切换。

-rw-r-----. 1 mysql mysql 239621 Oct 20 11:32 binlog.000019

-rw-r-----. 1 mysql mysql 249 Oct 20 16:28 binlog.000020

-rw-r-----. 1 mysql mysql 3783715 Oct 20 21:54 binlog.000021

-rw-r-----. 1 mysql mysql 16632 Oct 21 08:19 binlog.000022

-rw-r-----. 1 mysql mysql 249 Oct 21 08:21 binlog.000023

-rw-r-----. 1 mysql mysql 249 Oct 21 08:22 binlog.000024

-rw-r-----. 1 mysql mysql 65965 Oct 21 11:23 binlog.000025

-rw-r-----. 1 mysql mysql 270 Oct 21 14:23 binlog.000026

-rw-r-----. 1 mysql mysql 230 Oct 21 14:23 binlog.000027

不知道大家看到这里有什么收获呢。我们来解析一下，找一个有日志内容的文件，比如binlog.000025

mysql> show binlog events in 'binlog.000025';

最后一条信息就很有意思了。

| Log_name | Pos | Event_type | Server_id | End_log_pos | Info

| binlog.000025 | 65925 | Rotate | 228048 | 65965 | binlog.000026;pos=4

终止偏移量是65965，这个值和系统层面的binlog文件大小是一致的。所以明白了这一点之后，对于偏移量的理解又明白了一些。

而binlog里面存在大量的event,比如这里末尾的Rotate是什么意思呢。

是max_binlog_size的值或者执行flush logs命令时，binlog会发生切换，指向下一个binlog，其实偏移量还是4，但是如果是从库应用，就会是另外一个值，比如154或者更高的一个值。

得到这样一个值的意义是什么呢，我们就可以根据偏移量来计算数据变化的情况，比如从库端的复制进度，这些都是可以做出评估的。

更多的内容就需要看看源码里面是怎么写的了。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-2146960/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23718752/viewspace-2146960/