MySQL從庫com_insert無變化的原因

來源：懂視網(wǎng) 責(zé)編：小采時(shí)間：2020-11-09 19:17:22

MySQL從庫com_insert無變化的原因

MySQL從庫com_insert無變化的原因:大家都知道com_insert等com_xxx參數(shù)可以用來監(jiān)控?cái)?shù)據(jù)庫實(shí)例的訪問量，也就是我們常說的QPS。并且基于MySQL的復(fù)制原理，所有主庫執(zhí)行的操作都會(huì)在從庫重放一遍保證數(shù)據(jù)一致，那么主庫的com_insert和從庫的com_insert理論上應(yīng)該是相等的。如下面顯示，第二列

推薦度：

點(diǎn)擊下載本文 文檔為doc格式

導(dǎo)讀MySQL從庫com_insert無變化的原因:大家都知道com_insert等com_xxx參數(shù)可以用來監(jiān)控?cái)?shù)據(jù)庫實(shí)例的訪問量，也就是我們常說的QPS。并且基于MySQL的復(fù)制原理，所有主庫執(zhí)行的操作都會(huì)在從庫重放一遍保證數(shù)據(jù)一致，那么主庫的com_insert和從庫的com_insert理論上應(yīng)該是相等的。如下面顯示，第二列

大家都知道com_insert等com_xxx參數(shù)可以用來監(jiān)控?cái)?shù)據(jù)庫實(shí)例的訪問量，也就是我們常說的QPS。并且基于MySQL的復(fù)制原理，所有主庫執(zhí)行的操作都會(huì)在從庫重放一遍保證數(shù)據(jù)一致，那么主庫的com_insert和從庫的com_insert理論上應(yīng)該是相等的。
如下面顯示，第二列代表主庫，第三列代表從庫：

com_select22 1138com_update36 37com_insert 133135com_delete 00qcache_hits00Com_replace00Connections 13 24

但是我們看另外一個(gè)業(yè)務(wù)：

com_select 0 95com_update 00com_insert920com_delete200qcache_hits06Com_replace00Connections06

我們可以很明顯的看出來，主庫有92個(gè)寫，但是從庫0個(gè)寫，這是為什么呢？

這2個(gè)業(yè)務(wù)唯一的區(qū)別就是binlog_format的設(shè)置不一樣。

第一個(gè)業(yè)務(wù)
show global variables like '%binlog_format%';+---------------+-----------+| Variable_name | Value |+---------------+-----------+| binlog_format | STATEMENT |+---------------+-----------+
第二個(gè)業(yè)務(wù)
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是如何運(yùn)作的，但是并不能解釋為什么使用RBR之后com_insert就不變化了。

接下來我們結(jié)合下面這段文檔來一起看看。

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段話結(jié)合來看，原因應(yīng)該是這樣的：

1、主庫上接收的是statement的語句，所以com_insert符合觸發(fā)條件，會(huì)隨著業(yè)務(wù)增加。

2、而從庫是拿到主庫的binlog后重放更新數(shù)據(jù)，但是主庫的日志格式是row format，這就導(dǎo)致了binlog中記錄的不是statement語句，而是data的變化記錄。

3、這樣從庫雖然依然能進(jìn)行更新記錄，但是無法解析出來這些data變化是一條statement語句導(dǎo)致的還是多條statment語句導(dǎo)致，所以就不在更新com_insert這個(gè)statment counter了。

基本上推論符合現(xiàn)實(shí)情況，但是沒有code證明，比較遺憾。

另外，如果我們無法通過com_insert來監(jiān)控從庫的寫入情況，那么我們應(yīng)該監(jiān)控那個(gè)status呢？

個(gè)人建議對(duì)于row格式的實(shí)例，通過監(jiān)控innodb_rows_inserted來監(jiān)控寫入情況。

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

附：（兩個(gè)文檔的官方文檔鏈接）

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

聲明：本網(wǎng)頁內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com