MYSQL sync_relay_log對(duì)I/O thread的影響是怎樣的

MYSQL sync_relay_log對(duì)I/O thread的影響是怎樣的，針對(duì)這個(gè)問題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問題的小伙伴找到更簡單易行的方法。

搭建好的一套從庫，發(fā)現(xiàn)延遲很高，一直追不上，從庫的bin_log沒開，flush_log_at_trx_commit設(shè)置為0，
簡化的狀態(tài)如下：

mysql> show slave status \G
 1. row 
               Slave_IO_State: Queueing master event to the relay log
              Master_Log_File: mysql-bin.000533
          Read_Master_Log_Pos: 101151159
               Relay_Log_File: relaylog.000012
                Relay_Log_Pos: 897176
        Relay_Master_Log_File: mysql-bin.000533
          Exec_Master_Log_Pos: 99357144
        Seconds_Behind_Master: 11313
發(fā)現(xiàn)Master_Log_File,Read_Master_Log_Pos一直進(jìn)展比較緩慢，一般來說內(nèi)網(wǎng)的瓶頸不會(huì)在網(wǎng)絡(luò)，那么只可能在I/O
查看服務(wù)器I/O情況如下：


發(fā)現(xiàn)MYSQL線程LWP號(hào)為44706 的線程I/O非常高，但是寫入只有600來K，明顯這種情況是不正常的，一般來說LINUX
有KERNEL BUFFER/CACHE，write只是寫入到KERNEL BUFFER/CACHE就好了，例外就是以dirctor寫入方式，這種方式
依賴的是用戶態(tài)緩存，還有就是寫入調(diào)用了大量的fsync之類的同步kernel cache/buffer到磁盤的系統(tǒng)調(diào)用。
然后查看這個(gè)LWP號(hào)是否為I/O thread如下，因?yàn)?.7可以非常輕松的找到MYSQL conn_id和系統(tǒng)LWP之間的關(guān)系如下：

確實(shí)發(fā)現(xiàn)這個(gè)大量I/O的確實(shí)是MYSQL從庫的I/O thread，那么接下來的就是進(jìn)行strace看看到底為什么這么慢，strace
片段如下：


我們發(fā)現(xiàn)文件描述符fd=50的文件有大量的寫入而且頻繁的調(diào)用fdatasync來同步磁盤，消耗時(shí)間非常可觀，是MUTEX調(diào)用和write
操作的N倍
那么我們就看看文件描述符50到底是什么如下：

確實(shí)是我們的replay log。
那么問題就確定了，就是因?yàn)閞eplay log的寫入調(diào)用了大量的fdatasync造成的I/O THREAD非常慢，那么是哪一個(gè)參數(shù)呢？
其實(shí)參數(shù)就是sync_relay_log，這個(gè)參數(shù)用來保證relay log的安全，官方文檔有如下的圖：
GTID|sync_relay_log|MASTER_AUTO_POSITION|relay_log_recovery|relay_log_info_repository|Crash type|Recovery guaranteed |Relay  log impact
OFF           1           Any                1                   TABLE                   Any               Yes                    Lost
OFF           >1          Any                1                   TABLE                  Server            Yes                    Lost
OFF           >1          Any                1                    Any                     OS                No                     Lost
OFF           1           Any                0                   TABLE                  Server             Yes                  Remains
OFF           1           Any                0                   TABLE                    OS                No                   Remains
ON           Any          ON                Any                   Any                     Any             Yes                    Lost
ON            1           OFF                0                   TABLE                  Server            Yes                  Remains
ON            1           OFF                0                    Any                      OS                 No                   Remains

我們可以看到如果不設(shè)置sync_relay_log那么有可能造成relay log丟失的風(fēng)險(xiǎn)，其實(shí)上面的分析已經(jīng)看到就是調(diào)用fdatasync來完成這個(gè)功能，但是
這樣的代價(jià)基本是不可接受的。官方文檔有如下說明：
It is important to note the impact of sync_relay_log=1, which requires a write of to the relay log
per transaction. Although this setting is the most resilient to an unexpected halt, with at most one
unwritten transaction being lost, it also has the potential to greatly increase the load on storage. Without
sync_relay_log=1, the effect of an unexpected halt depends on how the relay log is handled by the
operating system. 
A value of 1 is the safest choice because in the event of a crash you lose at most one event from the
relay log. However, it is also the slowest choice (unless the disk has a battery-backed cache, which
makes synchronization very fast).
每次事物都會(huì)調(diào)用fdatasync，代價(jià)太高。所以沒辦法修改了sync_relay_log的設(shè)置，默認(rèn)值是10000，也就是10000個(gè)事物進(jìn)行一次
fdatasync。

關(guān)于MYSQL sync_relay_log對(duì)I/O thread的影響是怎樣的問題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關(guān)注億速云行業(yè)資訊頻道了解更多相關(guān)知識(shí)。