MySQL“异象”分析:备库的io util比主库重?

同事问了个线上现象:主备机器配置一样,主库上有更新查询,备库设置为主库的从库,没有其他更新和查询压力。但备库的io util比主库的重。本来看主库的压力比较大,想把一部分查询切到备库,一看io这样,不太敢切。

1、原因

这个原因两年前在之前公司碰到过一次,只是现象不同。那个现象描述起来比较复杂,这回刚好借这个现象说明一下。

原因还是从srv_master_thread说起。这个InnoDB后台的主进程一直在循环作各种事情。其中有一个for (i = 0; i < 10; i++) ,循环体每执行一次sleep 1秒,作一些flush和merge的事情,网上这类文章很多,不细数了。我们要关注的是循环中的这句话


if (srv_activity_count == old_activity_count) {

/* There is no user activity at the moment, go to

the background loop */

goto background_loop;

}

注释也说的明白,如果此时没有用户活动,则认为是系统空闲,执行background_loop。这个background_loop流程作的事情包括insert buffer merge和 flush buffer pool pages。 都是些耗系统资源的活儿。做完之后又回到for前面的逻辑。

而对于从库来说,一直没有用户请求,所以一进入for就符合进入background_loop的条件,所以整个线程实际上就是不停的在作background_loop里面的事情。

所以结论就是由于没有用户请求,InnoDB认为系统空闲,因此玩儿命地刷盘,看上去io就很重。

2、 验证

既然如此,就想办法告诉InnoDB:其实现在很忙。 可以简单的写个脚本不停的执行一个简单的语句,让if (srv_activity_count == old_activity_count)这条件不满足就行。比如 select sql_no_cache * from t where key = xxx limit 1;

会看到加了这脚本后,备库的io util也下去了。

3、 结论

切点查询流量去备库没有问题,反而会让备库看上去“正常” ;

InnoDB的这个判断机制有点囧,实际上有很多条件都可以比较合理的判断,不过也不是什么大问题,好歹还有些方法可以绕过的嘛,就是土了点。。。

时间: 2024-10-25 14:02:53

MySQL“异象”分析:备库的io util比主库重?的相关文章

MySQL · 捉虫动态 · 备库1206错误问题说明

问题背景 一个用户自建MySQL,出现备库复制中断的问题,报错为slave sql thread 错误,The total number of locks exceeds the lock table size. 报错代码 这个报错在代码中的抛错逻辑为: if UT_LIST_GET_LEN(buf_pool->free) + UT_LIST_GET_LEN(buf_pool->LRU) < buf_pool->curr_size / 4 文字解释是:如果buffer pool中的

PostgreSQL源码分析 备库查询冲突 - User was holding shared buffer pin for too long

背景 PostgreSQL 的基于流复制的物理备库是基于redo的物理块复制备库,允许开放只读的功能,但是需要注意,由于主库可能不断的产生redo,这些redo可能会与备库的QUERY产生冲突. 什么情况下query会堵塞.或与恢复冲突? 当以下操作产生的REDO被复制到备库,并且备库准备拿这些REDO来恢复时. Access Exclusive locks taken on the primary server, including both explicit LOCK commands an

PgSQL · 特性分析 · 备库激活过程分析

前言 PostgreSQL standby 可以通过两种方法来激活成为主库: trigger file,配置在recovery.conf中. pg_ctl promote发送SIGUSR1信号给postmaster进程. 同时,PostgreSQL支持快速激活(fast promote)和非快速激活(fallback promote): fast promote 开启数据库读写前,不需要做检查点.而是推到开启读写之后执行一个CHECKPOINT_FORCE检查点. fallback_promot

数据库内核月报 - 2015 / 08-PgSQL · 答疑解惑 · RDS中的PostgreSQL备库延迟原因分析

背景 在RDS环境中,多租户使用同一台主机是很常见的事情,为了隔离用户资源,有很多手段,例如使用虚拟机,或者CGROUP技术.以CGROUP为例,可以控制进程的CPU使用.内存使用.块设备的IOPS或者吞吐速率等资源使用.限制资源的好处是可以在共用的硬件层面为多个用户提供承诺的性能指标.当然这种方法也有一定的弊端,例如当用户需要运行消耗较多资源的SQL的时候,无法利用机器的空闲资源,因为它被限制住了.还有一些弊端可能导致RDS的不稳定,本文将展开讨论其中的弊端之一,资源限制是如何导致备库延迟的.

PostgreSQL物理&quot;备库&quot;的哪些操作或配置,可能影响&quot;主库&quot;的性能、垃圾回收、IO波动

标签 PostgreSQL , 物理复制 , 垃圾回收 , vacuum_defer_cleanup_age , hot_standby_feedback , max_standby_archive_delay , max_standby_streaming_delay 背景 PostgreSQL 物理备库的哪些配置,或者哪些操作,可能影响到主库呢? 首先,简单介绍一下PostgreSQL的物理备库,物理备库就是基于PostgreSQL WAL流式复制,实时恢复的备库.物理备库在物理层面与主库完

MySQL复制(2) 主备库都为空的情况下创建主备复制

本文适用于新安装的主库和备库,假定主备库为空,如果你是从已存在的主库复制,请转到<[MySQL] 复制(3)- 创建主备复制(从另一个服务器开始复制)> 主库的配置 主库需要打开二进制日志,并制定一个唯一的server id,my.cnf文件中增加或修改如下内容: server_id=60 log-bin = /data/mysql/log/mysql-bin 备库的配置 备库my.cnf的配置如下: server_id=61 read_only=1 log_bin = /data/mysql

备库报警邮件的分析案例(二)

在第一篇中分享了关于备库报警邮件的分析,发现很多问题都是一环扣一环. 起初是通过监控主库中的v$dataguard_status发现备库中可能存在一些问题,结果逐步分析,发现是由备库的crontab触发了备库的定时read-only和online状态,(即只读和应用日志,10gR2的环境),而这些关键信息都是从数据库的alert日志中发现的,但是问题还没有完,才刚刚开始,因为发现备库中竟然有ORA-1652: unable to extend temp segment by 128 in tab

11g备库无法开启ADG的原因分析

今天碰到一个有些奇怪的问题,但是奇怪的现象背后都是有本质的因果. 下午在做一个环境的检查时,发现备库是在mount阶段,这可是一个11gR2的库,没有ADG实在是太浪费了,对于这种情况感觉太不应该了. 所以尝试启动至open阶段,发现状态一直是read only,在ADG中应该是READ ONLY WITH APPLY才对啊. 使用dg broker设置为READ-ONLY,备库的数据库日志如下:      Standby Database:           stestdb3, Enable

【DATAGUARD】 将11g物理备库转换为Snapshot Standby

[DATAGUARD] 将11g物理备库转换为Snapshot Standby BLOG文档结构图         [DATAGUARD] 基于同一个主机建立物理备库和逻辑备库(一): http://blog.itpub.net/26736162/viewspace-1448197/[DATAGUARD] 基于同一个主机建立物理备库和逻辑备库(二 ):  http://blog.itpub.net/26736162/viewspace-1448207/[DATAGUARD] 基于同一个主机建立物