共計 2725 個字符，預計需要花費 7 分鐘才能閱讀完成。

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 的影響是怎樣的問題的解答就分享到這里了，希望以上內容可以對大家有一定的幫助，如果你還有很多疑惑沒有解開，可以關注丸趣 TV 行業資訊頻道了解更多相關知識。