在搭建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或者更高的一个值。
得到这样一个值的意义是什么呢，我们就可以根据偏移量来计算数据变化的情况，比如从库端的复制进度，这些都是可以做出评估的。
更多的内容就需要看看源码里面是怎么写的了。
