共计 2781 个字符，预计需要花费 7 分钟才能阅读完成。
这篇文章给大家分享的是有关 MySQL 中延迟问题和数据刷盘策略流程的示例分析的内容。丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，一起跟随丸趣 TV 小编过来看看吧。
一、MySQL 复制流程
官方文档流程如下：
MySQL 延迟问题和数据刷盘策略
1、绝对的延时，相对的同步
2、纯写操作，线上标准配置下，从库压力大于主库，最起码从库有 relaylog 的写入。
二、MySQL 延迟问题分析
1、主库 DML 请求频繁
原因：主库并发写入数据，而从库为单线程应用日志，很容易造成 relaylog 堆积，产生延迟。
解决思路：做 sharding，打散写请求。考虑升级到 MySQL5.7+，开启基于逻辑时钟的并行复制。
2、主库执行大事务
原因：类似主库花费很长时间更新了一张大表，在主从库配置相近的情况下，从库也需要花几乎同样的时间更新这张大表，此时从库延迟开始堆积，后续的 events 无法更新。
解决思路：拆分大事务，及时提交。
3、主库对大表执行 DDL 语句
原因：DDL 未开始执行，被阻塞，检查到位点不变；DDL 正在执行，单线程应用导致延迟增加，位点不变。
解决思路：找到被阻塞 DDL 或是写操作的查询，干掉该查询，让 DDL 正常在从库上执行；业务低峰期执行，尽量使用支持 OnlineDDL 的高版本 MySQL。
4、主从实例配置不一致
原因：硬件上：主库实例服务器使用 SSD，而从库实例服务器使用普通 SAS 盘、cpu 主频不一致等；配置上：如 RAID 卡写策略不一致，OS 内核参数设置不一致，MySQL 落盘策略 (innodb_flush_log_at_trx_commit 和 sync_binlog 等) 不一致等
解决思路：尽量统一 DB 机器的配置（包括硬件及选项参数）；甚至对于某些 OLAP 业务，从库实例硬件配置高于主库等。
5、从库自身压力过大
原因：从库执行大量 select 请求，或业务大部分 select 请求被路由到从库实例上，甚至大量 OLAP 业务，或者从库正在备份等，此时可能造成 cpu 负载过高，io 利用率过高等，导致 SQLThread 应用过慢。
解决思路：建立更多西安数据库培训从库，打散读请求，降低现有从库实例的压力。
也可以调整 innodb_flush_log_at_trx_commit= 0 和 sync_binlog= 0 刷盘参数来缓解 IO 压力来降低主从延迟。
三、大促期间 CPU 过高问题
现象：
高并发导致 CPU 负载过高，处理请求时间拉长，逐步积压，最终导致服务不可用；大量的慢 SQL 导致 CPU 负载过高。
解决思路：
基本上是禁止或是慎重考虑数据库主从切换，这个解决不了根本问题，需要研发配合根治 SQL 问题，也可以服务降级，容器的话可以动态扩容 CPU；和业务协商启动 pt-kill 查杀只读慢 SQL；查看是否可以通过增加一般索引或是联合索引来解决慢 SQL 问题，但此时要考虑 DDL 对数据库影响。
四、InnoDB 刷盘策略
MySQL 的 innodb_flush_method 这个参数控制着 innodb 数据文件及 redolog 的打开、刷写模式，对于这个参数，文档上是这样描述的：
有三个值：fdatasync(默认)，O_DSYNC，O_DIRECT
默认是 fdatasync，调用 fsync()去刷数据文件与 redolog 的 buffer
为 O_DSYNC 时，innodb 会使用 O_SYNC 方式打开和刷写 redolog, 使用 fsync()刷写数据文件
为 O_DIRECT 时，innodb 使用 O_DIRECT 打开数据文件，使用 fsync()刷写数据文件跟 redolog
首先文件的写操作包括三步：open,write,flush
上面最常提到的 fsync(intfd)函数，该函数作用是 flush 时将与 fd 文件描述符所指文件有关的 buffer 刷写到磁盘，并且 flush 完元数据信息 (比如修改日期、创建日期等) 才算 flush 成功。
使用 O_DSYNC 方式打开 redo 文件表示当 write 日志时，数据都 write 到磁盘，并且元数据也需要更新，才返回成功。
O_DIRECT 则表示我们的 write 操作是从 MySQLinnodbbuffer 里直接向磁盘上写。
这三种模式写数据方式具体如下：
fdatasync 模式：写数据时，write 这一步并不需要真正写到磁盘才算完成（可能写入到操作系统 buffer 中就会返回完成），真正完成是 flush 操作，buffer 交给操作系统去 flush, 并且文件的元数据信息也都需要更新到磁盘。
O_DSYNC 模式：写日志操作是在 write 这步完成，而数据文件的写入是在 flush 这步通过 fsync 完成
O_DIRECT 模式：数据文件的写入操作是直接从 mysqlinnodbbuffer 到磁盘的，并不用通过操作系统的缓冲，而真正的完成也是在 flush 这步, 日志还是要经过 OS 缓冲。
MySQL 延迟问题和数据刷盘策略
1、在类 unix 操作系统中，文件的打开方式为 O_DIRECT 会最小化缓冲对 io 的影响，该文件的 io 是直接在用户空间的 buffer 上操作的，并且 io 操作是同步的，因此不管是 read()系统调用还是 write()系统调用，数据都保证是从磁盘上读取的；所以 IO 方面压力最小，对于 CPU 处理压力上也最小，对物理内存的占用也最小；但是由于没有操作系统缓冲的作用，对于数据写入磁盘的速度会降低明显（表现为写入响应时间的拉长），但不会明显造成整体 SQL 请求量的降低（这有赖于足够大的 innodb_buffer_pool_size）。
2、O_DSYNC 方式表示以同步 io 的方式打开文件，任何写操作都将阻塞到数据写入物理磁盘后才返回。这就造成 CPU 等待加长，SQL 请求吞吐能力降低，insert 时间拉长。
3、fsync(intfiledes)函数只对由文件描述符 filedes 指定的单一文件起作用，并且等待写磁盘操作结束，然后返回。fdatasync(intfiledes)函数类似于 fsync，但它只影响文件的数据部分。而除数据外，fsync 还会同步更新文件的元信息到磁盘。
O_DSYNC 对 CPU 的压力最大，datasync 次之，O_DIRECT 最小；整体 SQL 语句处理性能和响应时间看，O_DSYNC 较差；O_DIRECT 在 SQL 吞吐能力上较好（仅次于 datasync 模式），但响应时间却是最长的。
默认 datasync 模式，整体表现较好，因为充分利用了操作系统 buffer 和 innodb_buffer_pool 的处理性能，但带来的负面效果是 free 内存降低过快，最后导致页交换频繁，磁盘 IO 压力大，这会严重影响大并发量数据写入的稳定性。
感谢各位的阅读！关于“MySQL 中延迟问题和数据刷盘策略流程的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，让大家可以学到更多知识，如果觉得文章不错，可以把它分享出去让更多的人看到吧！
