MYSQL sync

共计 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 行业资讯频道了解更多相关知识。