Mysql 5.7 Gtid內(nèi)部學(xué)習(xí)(九) 實(shí)際案例(一)

本案例是一個(gè)朋友的案例他也寫(xiě)了出來(lái)如下：
https://mp.weixin.qq.com/s/XSnFkuYzIlGWMaXIl-oPeQ
但是和他交流后他也準(zhǔn)備改因?yàn)榉治鲇幸恍┬?wèn)題。

一、觸發(fā)條件

• binlog_gtid_simple_recovery=false。
• 5.7.6以上版本。
• Gtid 關(guān)閉或者Gtid中途開(kāi)啟有大量的未開(kāi)啟Gtid的binlog。

二、本案例回顧

• 版本：MySQL版本 5.7.19。
• 故障為：大概每半小時(shí)發(fā)生一次故障，整個(gè)Mysql壓力巨大，很多簡(jiǎn)單的操作都相應(yīng)緩慢。使用iotop，top等工具都發(fā)現(xiàn)Mysql某個(gè)線程有大量的I/O。
• 分析方法：使用strace發(fā)現(xiàn)有大量的binlog文件讀取。
• binlog_gtid_simple_recovery=false。
• Gtid關(guān)閉，中途開(kāi)啟，但是留下了很多未開(kāi)啟Gtid的binlog。
• 數(shù)據(jù)庫(kù)沒(méi)有重啟，但是由于expire_logs_days觸發(fā)了binlog刪除。

三、故障分析

其實(shí)本案例就是前文第七部分總結(jié)中的：

Gtid關(guān)閉，simple_recovery=flase
5.7.6以上:這種方式一定得到正確的Gtid集合
重啟Mysql不掃秒全部的binlog，如果是中途打開(kāi)GTID重啟任然需要掃描多個(gè)binlog因?yàn)樾枰业紾tid event。
purge binlog或者超過(guò)參數(shù)expire_logs_days參數(shù)設(shè)置不觸發(fā)全binlog掃描，如果是中途打開(kāi)GTID重啟任然需要掃描多個(gè)binlog因?yàn)樾枰业紾tid event。 

從案例中我們得知是中途開(kāi)啟的Gtid，但是留下了很多未開(kāi)啟Gtid的binlog，從第六部分源碼bool MYSQL_BIN_LOG::init_gtid_sets()函數(shù)的分析，我們知道刪除binlog后也會(huì)觸發(fā)正向查找來(lái)獲取gtid_purged(Gtid_state.lost_gtids)。當(dāng)讀取到第一個(gè)binlog的時(shí)候雖然獲取到了PREVIOUS GTID EVENT但是沒(méi)有GTID EVENT，而simple_recovery=flase所以需要繼續(xù)查找下一個(gè)文件，直到找到同時(shí)包含PREVIOUS GTID EVENT和GTID EVENT的 那個(gè)binlog才會(huì)停止，那么顯然這種情況下那些Gtid關(guān)閉的時(shí)候生成的binlog將會(huì)全部掃描一遍，如果量大那么代價(jià)將是巨大的。
而案例中每半個(gè)小時(shí)會(huì)觸發(fā)一次binlog切換，因?yàn)橛|發(fā)超過(guò)expire_logs_days參數(shù)設(shè)置導(dǎo)致binlog進(jìn)行刪除，觸發(fā)了大量的binlog掃描。
顯然有了前面的基礎(chǔ)這個(gè)案例很容易分析。

四、案例模擬

這個(gè)案例非常好模擬。我打算直接使用strace查看。因?yàn)椴皇敲课慌笥讯寄芊奖闶褂肎DB調(diào)試。
使用測(cè)試版本社區(qū)版本5.7.17：

+---------------+-----------+
| Log_name      | File_size |
+---------------+-----------+
| binlog.000027 |       198 |
| binlog.000028 |       198 |
| binlog.000029 |       198 |
| binlog.000030 |       198 |
| binlog.000031 |       198 |
| binlog.000032 |       198 |
| binlog.000033 |       198 |
| binlog.000034 |       198 |
| binlog.000035 |       198 |
| binlog.000036 |       198 |
| binlog.000037 |       198 |
| binlog.000038 |       198 |
| binlog.000039 |       198 |
| binlog.000040 |       198 |
| binlog.000041 |       198 |
| binlog.000042 |       198 |
| binlog.000043 |       154 |
+---------------+-----------+

mysql> show variables like '%gtid%';
+----------------------------------+-----------+
| Variable_name                    | Value     |
+----------------------------------+-----------+
| binlog_gtid_simple_recovery      | OFF       |
| enforce_gtid_consistency         | ON        |
| gtid_executed_compression_period | 1000      |
| gtid_mode                        | OFF       |
| gtid_next                        | AUTOMATIC |
| gtid_owned                       |           |
| gtid_purged                      |           |
| session_track_gtids              | OFF       |
+----------------------------------+-----------+
8 rows in set (0.02 sec)
mysql> show variables like '%expir%';
+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
| disconnect_on_expired_password | ON    |
| expire_logs_days               | 1     |
+--------------------------------+-------+
2 rows in set (0.06 sec) 

然后我修改了系統(tǒng)時(shí)間同時(shí)Mysql開(kāi)啟Gtid

[root@test1 ~]# date -s '2017-12-13 10:10:10'
Wed Dec 13 10:10:10 CST 2017
mysql> set global gtid_mode=1;
Query OK, 0 rows affected (0.02 sec)

mysql> set global gtid_mode=2;
Query OK, 0 rows affected (0.01 sec)

mysql> set global gtid_mode=3;
Query OK, 0 rows affected (0.02 sec)

mysql> show variables like '%gtid_mode%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| gtid_mode     | ON    |
+---------------+-------+
1 row in set (0.02 sec) 

到一步我們已經(jīng)達(dá)到了觸發(fā)的標(biāo)準(zhǔn)，只要手動(dòng)觸發(fā)一次flush binary logs，讓binlog刷新就會(huì)看到。當(dāng)然線上是binlog滿了做的切換。
這個(gè)時(shí)候開(kāi)始做strace，并且做flush tables，我們觀察到

mysql> flush binary logs;
Query OK, 0 rows affected (0.30 sec)

strace：

[pid  6551] 10:17:15.936738 read(62, "/mysql/mysql5.7.17/binlog.000027"..., 528) = 528 <0.000039>
[pid  6551] 10:17:15.936834 stat("/mysql/mysql5.7.17/binlog.000027", {st_mode=S_IFREG|0640, st_size=198, ...}) = 0 <0.000025>
[pid  6551] 10:17:15.936925 lseek(3, 0, SEEK_SET) = 0 <0.000017>
[pid  6551] 10:17:15.936983 read(3, "/mysql/mysql5.7.17/binlog.000043"..., 165) = 165 <0.000018>
[pid  6551] 10:17:15.937076 lstat("/mysql", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 <0.000020>
[pid  6551] 10:17:15.937144 lstat("/mysql/mysql5.7.17", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 <0.000586>
[pid  6551] 10:17:15.937819 unlink("/mysql/mysql5.7.17/binlog.000027") = 0 <0.000109>
[pid  6551] 10:17:15.938009 stat("/mysql/mysql5.7.17/binlog.000028", {st_mode=S_IFREG|0640, st_size=198, ...}) = 0 <0.000021>
[pid  6551] 10:17:15.938119 lstat("/mysql", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 <0.000020>
[pid  6551] 10:17:15.938228 lstat("/mysql/mysql5.7.17", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 <0.000021>
[pid  6551] 10:17:15.938314 unlink("/mysql/mysql5.7.17/binlog.000028") = 0 <0.000073>
.....
[pid  6551] 10:17:15.954677 lstat("/mysql/mysql5.7.17", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 <0.000019>
[pid  6551] 10:17:15.954756 unlink("/mysql/mysql5.7.17/binlog.000041") = 0 <0.000099>
[pid  6551] 10:17:15.954920 stat("/mysql/mysql5.7.17/binlog.000042", {st_mode=S_IFREG|0640, st_size=198, ...}) = 0 <0.000021>
[pid  6551] 10:17:15.955022 lstat("/mysql", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 <0.000018>
[pid  6551] 10:17:15.955087 lstat("/mysql/mysql5.7.17", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 <0.000018>
[pid  6551] 10:17:15.955159 unlink("/mysql/mysql5.7.17/binlog.000042") = 0 <0.000130> 

受限篇幅我這里刪除了一些。我們看到很多read/lseek系統(tǒng)調(diào)用正是讀取binlog的證據(jù)。
至此整個(gè)案例模擬完成。

五、總結(jié)

前文已經(jīng)描述過(guò)在5.7.6以上binlog_gtid_simple_recovery應(yīng)該設(shè)置為true，這樣可以避免可能的大量的binlog的掃描。具體分析可以參考第七節(jié)和從第六部分源碼bool MYSQL_BIN_LOG::init_gtid_sets()函數(shù)的分析。

作者微信：