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。

作者微信：

               

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/7728585/viewspace-2137737/，如需轉載，請註明出處，否則將追究法律責任。