英文版网站怎么做,家谱网站的首页怎么做,百度中心,校园二手网站开发与设计任务书一、MySQL复制流程官方文档流程如下#xff1a;MySQL延迟问题和数据刷盘策略1、绝对的延时#xff0c;相对的同步2、纯写操作#xff0c;线上标准配置下#xff0c;从库压力大于主库#xff0c;最起码从库有relaylog的写入。二、MySQL延迟问题分析1、主库DML请求频繁原因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_commit0和sync_binlog0刷盘参数来缓解IO压力来降低主从延迟。三、大促期间CPU过高问题现象高并发导致CPU负载过高处理请求时间拉长逐步积压最终导致服务不可用大量的慢SQL导致CPU负载过高。解决思路基本上是禁止或是慎重考虑数据库主从切换这个解决不了根本问题需要研发配合根治SQL问题也可以服务降级容器的话可以动态扩容CPU和业务协商启动pt-kill查杀只读慢SQL查看是否可以通过增加一般索引或是联合索引来解决慢SQL问题但此时要考虑DDL对数据库影响。四、InnoDB刷盘策略MySQL的innodb_flush_method这个参数控制着innodb数据文件及redolog的打开、刷写模式对于这个参数文档上是这样描述的有三个值fdatasync(默认)O_DSYNCO_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延迟问题和数据刷盘策略流程分析希望对大家有所帮助本文标题: MySQL延迟问题和数据刷盘策略流程分析本文地址: http://www.cppcns.com/shujuku/mysql/300594.html
