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或者更高的一個值。

得到這樣一個值的意義是什麼呢，我們就可以根據偏移量來計算資料變化的情況，比如從庫端的複製進度，這些都是可以做出評估的。

更多的內容就需要看看原始碼裡面是怎麼寫的了。