逐步分析MySQL從庫com_insert無變化的原因
大家都知道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
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/4822/viewspace-2804268/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 網站分析中常見的流量變化原因網站
- MYSQL 主從不一致的原因分析MySql
- hive初始化mysql資料庫失敗的原因HiveMySql資料庫
- 本地無法連線Mysql的原因MySql
- 11g備庫無法開啟ADG的原因分析
- 查詢滿足條件的最新資料(逐步優化,mysql、達夢資料庫)優化MySql資料庫
- EM agent無法啟動的原因及分析
- MySql事務無法回滾的原因有哪些MySql
- [譯]從 SQLite 逐步遷移到 RoomSQLiteOOM
- [譯] 從 SQLite 逐步遷移到 RoomSQLiteOOM
- Dataguard從庫日誌不同步的原因
- 如何從MySQL中將變化的事件資料釋出到Kafka?MySql事件Kafka
- 從MySQL原始碼看日誌命令失效的原因MySql原始碼
- 排序sql升級5.6變慢原因分析排序SQL
- MySQL資料庫的效能的影響分析及其優化MySql資料庫優化
- 備庫批量查詢失敗的原因分析
- 【mysql】mysql的資料庫主從(一主一從)MySql資料庫
- 搬瓦工香港VPS主機變慢的原因分析
- 逐步提升程式質量的演變過程示例
- mysql字元轉化以及亂碼原因MySql字元
- Windows變慢原因分析及解決方法(轉)Windows
- MYSQL建立使用者後本地無法登入的原因MySql
- 優化動畫卡頓:卡頓原因分析及優化方案優化動畫
- mysql資料庫連線過多的錯誤,可能的原因分析及解決辦法(轉)MySql資料庫
- MySQL複製過程中出現的從庫無法連線主庫的解決辦法MySql
- 從運維角度淺談 MySQL 資料庫優化運維MySql資料庫優化
- mysql xtracbakup 重建從庫 .MySql
- mysql資料庫在不同的伺服器,無法進行資料傳輸,或者匯入匯出資料錯誤,原因分析MySql資料庫伺服器
- oracle資料庫監聽啟動不了的原因分析Oracle資料庫
- MYSQL資料表損壞的原因分析和修復方法MySql
- IIS無法訪問動態連結庫DLL的原因
- 筆記本螢幕變暗的原因分析以及解決方法筆記
- 汽車自動變速器的三個常見故障原因分析
- 從GrowingIO產品到平臺的進化看資料分析的演變
- MySQL 5.7主從新增新從庫MySql
- 兩種簡單分析和優化MySQL資料庫表的方法優化MySql資料庫
- 從運維角度淺談MySQL資料庫最佳化運維MySql資料庫
- 故障分析 | MySQL 異地從庫複製延遲案例一則MySql