在搭建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/