最新文章专题视频专题问答1问答10问答100问答1000问答2000关键字专题1关键字专题50关键字专题500关键字专题1500TAG最新视频文章推荐1 推荐3 推荐5 推荐7 推荐9 推荐11 推荐13 推荐15 推荐17 推荐19 推荐21 推荐23 推荐25 推荐27 推荐29 推荐31 推荐33 推荐35 推荐37视频文章20视频文章30视频文章40视频文章50视频文章60 视频文章70视频文章80视频文章90视频文章100视频文章120视频文章140 视频2关键字专题关键字专题tag2tag3文章专题文章专题2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章专题3
问答文章1 问答文章501 问答文章1001 问答文章1501 问答文章2001 问答文章2501 问答文章3001 问答文章3501 问答文章4001 问答文章4501 问答文章5001 问答文章5501 问答文章6001 问答文章6501 问答文章7001 问答文章7501 问答文章8001 问答文章8501 问答文章9001 问答文章9501
当前位置: 首页 - 科技 - 知识百科 - 正文

MySQL从库com_insert无变化的原因_MySQL

来源:懂视网 责编:小采 时间:2020-11-09 19:17:24
文档

MySQL从库com_insert无变化的原因_MySQL

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

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

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

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

com_select 0 95com_update 0 0com_insert 92 0com_delete 20 0qcache_hits 0 6Com_replace 0 0Connections 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

声明:本网页内容旨在传播知识,若有侵权等问题请及时与本网联系,我们将在第一时间删除处理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

文档

MySQL从库com_insert无变化的原因_MySQL

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

最新推荐

猜你喜欢

热门推荐

专题
Top