逐步分析MySQL从库com_insert无变化的原因_Mysql

大家都知道com_insert等com_xxx参数可以用来监控数据库实例的访问量,也就是我们常说的QPS。并且基于MySQL的复制原理,所有主库执行的操作都会在从库重放一遍保证数据一致,那么主库的com_insert和从库的com_insert理论上应该是相等的。
如下面显示,第二列代表主库,第三列代表从库:

复制代码 代码如下:

com_select              22                 1138
com_update              36                   37
com_insert             133                  135
com_delete               0                    0
qcache_hits              0                    0
Com_replace              0                    0
Connections             13                   24

但是我们看另外一个业务:

复制代码 代码如下:

com_select               0                   95
com_update               0                    0
com_insert              92                    0
com_delete              20                    0
qcache_hits              0                    6
Com_replace              0                    0
Connections              0                    6

我们可以很明显的看出来,主库有92个写,但是从库0个写,这是为什么呢?

这2个业务唯一的区别就是binlog_format的设置不一样。

复制代码 代码如下:

第一个业务
show global variables like '%binlog_format%';
+---------------+-----------+
| Variable_name | Value     |
+---------------+-----------+
| binlog_format | STATEMENT |
+---------------+-----------+

第二个业务
show global variables like '%binlog_format%';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+

我们来看下com_xxx的官方文档定义:

The Com_xxx statement counter variables indicate the number of times each xxx statement has been executed. There is one status variable for each type of statement. For example, Com_delete and Com_update count DELETE and UPDATE statements, respectively. Com_delete_multi and Com_update_multi are similar but apply to DELETE and UPDATE statements that use multiple-table syntax.

从上述文档,我们只能看到com_xxx是如何运作的,但是并不能解释为什么使用RBR之后com_insert就不变化了。

接下来我们结合下面这段文档来一起看看。

You cannot examine the logs to see what statements were executed, nor can you see on the slave what statements were received from the master and executed.
However, you can see what data was changed using mysqlbinlog with the options --base64-output=DECODE-ROWS and --verbose.

这2段话结合来看,原因应该是这样的:

1、主库上接收的是statement的语句,所以com_insert符合触发条件,会随着业务增加。

2、而从库是拿到主库的binlog后重放更新数据,但是主库的日志格式是row format,这就导致了binlog中记录的不是statement语句,而是data的变化记录。

3、这样从库虽然依然能进行更新记录,但是无法解析出来这些data变化是一条statement语句导致的还是多条statment语句导致,所以就不在更新com_insert这个statment counter了。

基本上推论符合现实情况,但是没有code证明,比较遗憾。

另外,如果我们无法通过com_insert来监控从库的写入情况,那么我们应该监控那个status呢?

个人建议对于row格式的实例,通过监控innodb_rows_inserted来监控写入情况。

复制代码 代码如下:

show global status like 'innodb_rows_inserted';
+----------------------+------------+
| Variable_name        | Value      |
+----------------------+------------+
| Innodb_rows_inserted | 2666049650 |
+----------------------+------------+

附:(两个文档的官方文档链接)

http://dev.mysql.com/doc/refman/5.6/en/server-status-variables.html#statvar_Com_xxx

http://dev.mysql.com/doc/refman/5.5/en/replication-sbr-rbr.html

以上是小编为您精心准备的的内容,在的博客、问答、公众号、人物、课程等栏目也有的相关内容,欢迎继续使用右上角搜索按钮进行搜索MySQL从库
com_insert
mysql insert into、mysql insert、mysql 批量insert、mysql insert语句、mysql批量insert数据,以便于您获取更多的相关知识。

时间: 2024-11-08 21:16:55

逐步分析MySQL从库com_insert无变化的原因_Mysql的相关文章

MySQL · 特性分析 · MySQL 5.7 外部XA Replication实现及缺陷分析

MySQL 5.7 外部XA Replication实现及缺陷分析 MySQL 5.7增强了分布式事务的支持,解决了之前客户端退出或者服务器关闭后prepared的事务回滚和服务器宕机后binlog丢失的情况. 为了解决之前的问题,MySQL5.7将外部XA在binlog中的记录分成了两部分,使用两个GTID来记录.执行prepare的时候就记录一次binlog,执行commit/rollback再记录一次.由于XA是分成两部分记录,那么XA事务在binlog中就可能是交叉出现的.Slave端的

如何用SQLyog来分析MySQL数据库

用SQLyog来分析MySQL数据库: SOLyog的下载.安装以及使用很简单.我去了相关网站下载,它只有384K字节大小.它把两个文件(一个可执行文件.exe和一个动态链接库文件.dll)安装到C:\Program Files\SQLyog路径下.然后运行可执行文件. 安装后没有必要再访问该网站了,我访问该网站是得到了一个消息,说它的域名没有设置(configured).登记.或正在建设中.我不清楚这个问题是暂时的还是一直是这样.该软件是免费的,并且没有标志广告(banner ads),所以它

与MySQL客户端库的链接问题

当你链接到应用程序以使用MySQL客户端库时,可能会遇到以mysql_开始的未定义引用错误,如下所示: /tmp/ccFKsdPa.o: 在函数`main'中: /tmp/ccFKsdPa.o(.text+0xb): 对`mysql_init'的未定义引用. /tmp/ccFKsdPa.o(.text+0x31): 对`mysql_real_connect'的未定义引用. /tmp/ccFKsdPa.o(.text+0x57): 对`mysql_real_connect'的未定义引用. /tmp

创建MySQL从库

  我们知道Oracle有DataGuard实时备份数据,可以做主备切换,而MySQL也有自己的一套备库方案,称之为主从复制. 搭建MySQL从库是为了实时同步主库数据,同时也可以分担主库的读压力,对数据库端做成读写分离结构. 搭建MySQL主从库注意点: 1.主库和从库的 server-id 一定不能相同. 2.在主库创建replication slave账户. grant replication slave on *.* to 'repl'@'192.168.0.232' identifie

详细讲解如何用SQLyog来分析MySQL数据库

用SQLyog来分析MySQL数据库: SOLyog的下载.安装以及使用很简单.我去了相关网站下载,它只有384K字节大小.它把两个文件(一个可执行文件.exe和一个动态链接库文件.dll)安装到C:Program FilesSQLyog路径下.然后运行可执行文件. 安装后没有必要再访问该网站了,我访问该网站是得到了一个消息,说它的域名没有设置(configured).登记.或正在建设中.我不清楚这个问题是暂时的还是一直是这样.该软件是免费的,并且没有标志广告(banner ads),所以它可能

怎样保证mysql备库slave只读(授权)

怎样保证mysql备库slave只读(授权) slave服务器my.cnf上配置了read-only选项,为什么还可以在slave中插入/更新数据呢? 因为是使用具有super权限的帐号连接的,改用普通帐号就不行了,也就是授权时不能指定有super或all权限

求大神帮我分析分析mysql的错误日志

问题描述 求大神帮我分析分析mysql的错误日志 2016-02-17 08:42:20 5388 [Note] Plugin 'FEDERATED' is disabled. 2016-02-17 08:42:20 1828 InnoDB: Warning: Using innodb_additional_mem_pool_size is DEPRECATED. This option may be removed in future releases, together with the o

ubuntu-阿里云下 Tomcat 应用无法连接数Mysql据库

问题描述 阿里云下 Tomcat 应用无法连接数Mysql据库 1.程序没问题,在本机上调试无误,struts2 spting hibernate 2.在阿里云服务器上 配置了 JDK 1.7 + tomcat7 + mysql5.1 , OS:ubuntu64 3.将应用部署后,JSP 页面访问正常,只要涉及到连接数据库就会有如下提示 org.hibernate.exception.GenericJDBCException: Cannot open connection org.hiberna

mysql 声明式事务-声明式事务与mysql读写库配置问题

问题描述 声明式事务与mysql读写库配置问题 10C 原来项目用的spring声明式事务处理 现在需要加上mysql的读写库 应用层使用的是aop切换数据库连接 但是读的时候有时候是读库 有时候是写库 不知道是否和声明式事务处理有关 各位大大帮忙看看 applicationContext.xml <.....省略配置> <.....省略配置> <!-- write --> <!-- read --> tx:attributes <...省略...&g