MYSQL sync_relay_log對I/O thread的影響是怎樣的

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

搭建好的一套從庫，發現延遲很高，一直追不上，從庫的bin_log沒開，flush_log_at_trx_commit設置為0，
簡化的狀態如下：

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
發現Master_Log_File,Read_Master_Log_Pos一直進展比較緩慢，一般來說內網的瓶頸不會在網絡，那么只可能在I/O
查看服務器I/O情況如下：


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

確實發現這個大量I/O的確實是MYSQL從庫的I/O thread，那么接下來的就是進行strace看看到底為什么這么慢，strace
片段如下：


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

確實是我們的replay log。
那么問題就確定了，就是因為replay log的寫入調用了大量的fdatasync造成的I/O THREAD非常慢，那么是哪一個參數呢？
其實參數就是sync_relay_log，這個參數用來保證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

我們可以看到如果不設置sync_relay_log那么有可能造成relay log丟失的風險，其實上面的分析已經看到就是調用fdatasync來完成這個功能，但是
這樣的代價基本是不可接受的。官方文檔有如下說明：
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).
每次事物都會調用fdatasync，代價太高。所以沒辦法修改了sync_relay_log的設置，默認值是10000，也就是10000個事物進行一次
fdatasync。

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