如何監(jiān)控MySQL

首先介紹下 pt-stalk，它是 Percona-Toolkit 工具包中的一個(gè)工具，說(shuō)起 PT 工具包大家都不陌生，平時(shí)常用的 pt-query-digest、 pt-online-schema-change 等工具都是出自于這個(gè)工具包，這里就不多介紹了。

為婺城等地區(qū)用戶(hù)提供了全套網(wǎng)頁(yè)設(shè)計(jì)制作服務(wù)，及婺城網(wǎng)站建設(shè)行業(yè)解決方案。主營(yíng)業(yè)務(wù)為成都網(wǎng)站建設(shè)、網(wǎng)站制作、婺城網(wǎng)站設(shè)計(jì)，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專(zhuān)業(yè)、用心的態(tài)度為用戶(hù)提供真誠(chéng)的服務(wù)。我們深信只要達(dá)到每一位用戶(hù)的要求，就會(huì)得到認(rèn)可，從而選擇與我們長(zhǎng)期合作。這樣，我們也可以走得更遠(yuǎn)！

pt-stalk 的主要功能是在出現(xiàn)問(wèn)題時(shí)收集 OS 及 MySQL 的診斷信息，這其中包括：

1. OS 層面的 CPU、IO、內(nèi)存、磁盤(pán)、網(wǎng)絡(luò)等信息；

2. MySQL 層面的行鎖等待、會(huì)話連接、主從復(fù)制，狀態(tài)參數(shù)等信息。

而且 pt-stalk 是一個(gè) Shell腳本，對(duì)于我這種看不懂 perl 的人來(lái)說(shuō)比較友好，腳本里面的監(jiān)控邏輯與監(jiān)控命令也可以拿來(lái)參考，用于構(gòu)建自己的監(jiān)控體系。

三、使用

接著我們來(lái)看下如何使用這個(gè)工具。

pt-stalk 通常以后臺(tái)服務(wù)形式監(jiān)控 MySQL 并等待觸發(fā)條件，當(dāng)觸發(fā)條件時(shí)收集相關(guān)診斷數(shù)據(jù)。

觸發(fā)條件相關(guān)的參數(shù)有以下幾個(gè)：

function：

°?默認(rèn)為 status，代表監(jiān)控 SHOW GLOBAL STATUS 的輸出；

°?也可以設(shè)置為 processlist，代表監(jiān)控 show processlist 的輸出；

variable：

°?默認(rèn)為 Threads_running，代表 監(jiān)控參數(shù)，根據(jù)上述監(jiān)控輸出指定具體的監(jiān)控項(xiàng)；

threshold：

°?默認(rèn)為 25，代表 監(jiān)控閾值，監(jiān)控參數(shù)超過(guò)閾值，則滿(mǎn)足觸發(fā)條件；

°?監(jiān)控參數(shù)的值非數(shù)字時(shí)，需要配合 match 參數(shù)一起使用，如 processlist 的 state 列；

cycles：

°?默認(rèn)為 5，表示連續(xù)觀察到五次滿(mǎn)足觸發(fā)條件時(shí)，才觸發(fā)收集；

連接參數(shù)：host、password、port、socket。

其他一些重要參數(shù)：

iterations：該參數(shù)指定 pt-stalk 在觸發(fā)收集幾次后退出，默認(rèn)會(huì)一直運(yùn)行。

run-time：觸發(fā)收集后，該參數(shù)指定收集多長(zhǎng)時(shí)間的數(shù)據(jù)，默認(rèn) 30 秒。

sleep：該參數(shù)指定在觸發(fā)收集后，sleep 多久后繼續(xù)監(jiān)控，默認(rèn) 300 秒。

interval：指定狀態(tài)參數(shù)的檢查頻率，判斷是否需要觸發(fā)收集，默認(rèn) 1 秒。

dest：監(jiān)控?cái)?shù)據(jù)存放路徑，默認(rèn)為 /var/lib/pt-stalk。

retention-time ：監(jiān)控?cái)?shù)據(jù)保留時(shí)長(zhǎng)，默認(rèn) 30 天。

daemonize：以后臺(tái)服務(wù)運(yùn)行，默認(rèn)不開(kāi)啟。

log：后臺(tái)運(yùn)行日志，默認(rèn)為 /var/log/pt-stalk.log。

collect：觸發(fā)發(fā)生時(shí)收集診斷數(shù)據(jù)，默認(rèn)開(kāi)啟。

°?collect-gdb：收集 GDB 堆棧跟蹤，需要 gdb 工具。

°?collect-strace：收集跟蹤數(shù)據(jù)，需要 strace 工具。

°?collect-tcpdump：收集 tcpdump 數(shù)據(jù)，需要 tcpdump 工具。

MySQL 主從，5 分鐘帶你掌握

MySQL 主從一直是面試常客，里面的知識(shí)點(diǎn)雖然基礎(chǔ)，但是能回答全的同學(xué)不多。

比如樓哥之前面試小米，就被問(wèn)到過(guò)主從復(fù)制的原理，以及主從延遲的解決方案，因?yàn)榛卮鸬姆浅２诲e(cuò)，給面試官留下非常好的印象。你之前面試，有遇到過(guò)哪些 MySQL 主從的問(wèn)題呢？

所謂 MySQL 主從，就是建立兩個(gè)完全一樣的數(shù)據(jù)庫(kù)，一個(gè)是主庫(kù)，一個(gè)是從庫(kù)， 主庫(kù)對(duì)外提供讀寫(xiě)的操作，從庫(kù)對(duì)外提供讀的操作 ，下面是一主一從模式：

對(duì)于數(shù)據(jù)庫(kù)單機(jī)部署，在 4 核 8G 的機(jī)器上運(yùn)行 MySQL 5.7 時(shí)，大概可以支撐 500 的 TPS 和 10000 的 QPS， 當(dāng)遇到一些活動(dòng)時(shí)，查詢(xún)流量驟然，就需要進(jìn)行主從分離。

大部分系統(tǒng)的訪問(wèn)模型是讀多寫(xiě)少，讀寫(xiě)請(qǐng)求量的差距可能達(dá)到幾個(gè)數(shù)量級(jí)，所以我們可以通過(guò)一主多從的方式， 主庫(kù)只負(fù)責(zé)寫(xiě)入和部分核心邏輯的查詢(xún)，多個(gè)從庫(kù)只負(fù)責(zé)查詢(xún)，提升查詢(xún)性能，降低主庫(kù)壓力。

MySQL 主從還能做到服務(wù)高可用，當(dāng)主庫(kù)宕機(jī)時(shí)，從庫(kù)可以切成主庫(kù)，保證服務(wù)的高可用，然后主庫(kù)也可以做數(shù)據(jù)的容災(zāi)備份。

整體場(chǎng)景總結(jié)如下：

MySQL 的主從復(fù)制是依賴(lài)于 binlog 的，也就是記錄 MySQL 上的所有變化并以二進(jìn)制形式保存在磁盤(pán)上二進(jìn)制日志文件。

主從復(fù)制就是將 binlog 中的數(shù)據(jù)從主庫(kù)傳輸?shù)綇膸?kù)上，一般這個(gè)過(guò)程是異步的，即主庫(kù)上的操作不會(huì)等待 binlog 同步的完成。

詳細(xì)流程如下：

當(dāng)主庫(kù)和從庫(kù)數(shù)據(jù)同步時(shí)，突然中斷怎么辦？因?yàn)橹鲙?kù)與從庫(kù)之間維持了一個(gè)長(zhǎng)鏈接，主庫(kù)內(nèi)部有一個(gè)線程，專(zhuān)門(mén)服務(wù)于從庫(kù)的這個(gè)長(zhǎng)鏈接的。

對(duì)于下面的情況，假如主庫(kù)執(zhí)行如下 SQL，其中 a 和 create_time 都是索引：

我們知道，數(shù)據(jù)選擇了 a 索引和選擇 create_time 索引，最后 limit 1 出來(lái)的數(shù)據(jù)一般是不一樣的。

所以就會(huì)存在這種情況：在 binlog = statement 格式時(shí)，主庫(kù)在執(zhí)行這條 SQL 時(shí)，使用的是索引 a，而從庫(kù)在執(zhí)行這條 SQL 時(shí)，使用了索引 create_time，最后主從數(shù)據(jù)不一致了。

那么我們改如何解決呢？

可以把 binlog 格式修改為 row，row 格式的 binlog 日志記錄的不是 SQL 原文，而是兩個(gè) event:Table_map 和 Delete_rows。

Table_map event 說(shuō)明要操作的表，Delete_rows event用于定義要?jiǎng)h除的行為，記錄刪除的具體行數(shù)。 row 格式的 binlog 記錄的就是要?jiǎng)h除的主鍵 ID 信息，因此不會(huì)出現(xiàn)主從不一致的問(wèn)題。

但是如果 SQL 刪除 10 萬(wàn)行數(shù)據(jù)，使用 row 格式就會(huì)很占空間的，10 萬(wàn)條數(shù)據(jù)都在 binlog 里面，寫(xiě) binlog 的時(shí)候也很耗 IO。但是 statement 格式的 binlog 可能會(huì)導(dǎo)致數(shù)據(jù)不一致。

設(shè)計(jì) MySQL 的大叔想了一個(gè)折中的方案，mixed 格式的 binlog，其實(shí)就是 row 和 statement 格式混合使用， 當(dāng) MySQL 判斷可能數(shù)據(jù)不一致時(shí)，就用 row 格式，否則使用就用 statement 格式。

有時(shí)候我們遇到從數(shù)據(jù)庫(kù)中獲取不到信息的詭異問(wèn)題時(shí)，會(huì)糾結(jié)于代碼中是否有一些邏輯會(huì)把之前寫(xiě)入的內(nèi)容刪除，但是你又會(huì)發(fā)現(xiàn)，過(guò)了一段時(shí)間再去查詢(xún)時(shí)又可以讀到數(shù)據(jù)了，這基本上就是主從延遲在作怪。

主從延遲，其實(shí)就是“從庫(kù)回放” 完成的時(shí)間，與 “主庫(kù)寫(xiě) binlog” 完成時(shí)間的差值， 會(huì)導(dǎo)致從庫(kù)查詢(xún)的數(shù)據(jù)，和主庫(kù)的不一致 。

談到 MySQL 數(shù)據(jù)庫(kù)主從同步延遲原理，得從 MySQL 的主從復(fù)制原理說(shuō)起：

總結(jié)一下主從延遲的主要原因 ：主從延遲主要是出現(xiàn)在 “relay log 回放” 這一步，當(dāng)主庫(kù)的 TPS 并發(fā)較高，產(chǎn)生的 DDL 數(shù)量超過(guò)從庫(kù)一個(gè) SQL 線程所能承受的范圍，那么延時(shí)就產(chǎn)生了，當(dāng)然還有就是可能與從庫(kù)的大型 query 語(yǔ)句產(chǎn)生了鎖等待。

我們一般會(huì)把從庫(kù)落后的時(shí)間作為一個(gè)重點(diǎn)的數(shù)據(jù)庫(kù)指標(biāo)做監(jiān)控和報(bào)警，正常的時(shí)間是在毫秒級(jí)別，一旦落后的時(shí)間達(dá)到了秒級(jí)別就需要告警了。

解決該問(wèn)題的方法，除了縮短主從延遲的時(shí)間，還有一些其它的方法，基本原理都是盡量不查詢(xún)從庫(kù)。

具體解決方案如下：

在實(shí)際應(yīng)用場(chǎng)景中，對(duì)于一些非常核心的場(chǎng)景，比如庫(kù)存，支付訂單等，需要直接查詢(xún)從庫(kù)，其它非核心場(chǎng)景，就不要去查主庫(kù)了。

兩臺(tái)機(jī)器 A 和 B，A 為主庫(kù)，負(fù)責(zé)讀寫(xiě)，B 為從庫(kù)，負(fù)責(zé)讀數(shù)據(jù)。

如果 A 庫(kù)發(fā)生故障，B 庫(kù)成為主庫(kù)負(fù)責(zé)讀寫(xiě)，修復(fù)故障后，A 成為從庫(kù)，主庫(kù) B 同步數(shù)據(jù)到從庫(kù) A。

一臺(tái)主庫(kù)多臺(tái)從庫(kù)，A 為主庫(kù)，負(fù)責(zé)讀寫(xiě)，B、C、D為從庫(kù)，負(fù)責(zé)讀數(shù)據(jù)。

如果 A 庫(kù)發(fā)生故障，B 庫(kù)成為主庫(kù)負(fù)責(zé)讀寫(xiě)，C、D負(fù)責(zé)讀，修復(fù)故障后，A 也成為從庫(kù)，主庫(kù) B 同步數(shù)據(jù)到從庫(kù) A。

如何監(jiān)控MySQL主從同步情況

MySQL同步功能由3個(gè)線程(master上1個(gè)，slave上2個(gè))來(lái)實(shí)現(xiàn)，簡(jiǎn)單的說(shuō)就是：master發(fā)送日志一個(gè)，slave接收日志一個(gè)，slave運(yùn)行日志一個(gè)。

首先，我們解釋一下 show slave status 中重要的幾個(gè)參數(shù):

Slave_IO_Running： I/O線程是否被啟動(dòng)并成功地連接到主服務(wù)器上。

Slave_SQL_Running： SQL線程是否被啟動(dòng)。

Seconds_Behind_Master：

本字段是從屬服務(wù)器“落后”多少的一個(gè)指示。當(dāng)從屬SQL線程正在運(yùn)行時(shí)（處理更新），本字段為在主服務(wù)器上由此線程執(zhí)行的最近的一個(gè)事件的時(shí)間標(biāo)記開(kāi)始，已經(jīng)過(guò)的秒數(shù)。當(dāng)此線程被從屬服務(wù)器I/O線程趕上，并進(jìn)入閑置狀態(tài)，等待來(lái)自I/O線程的更多的事件時(shí)，本字段為零。總之，本字段測(cè)量從屬服務(wù)器SQL線程和從屬服務(wù)器I/O線程之間的時(shí)間差距，單位以秒計(jì)。

mysql主從同步延遲zabbix怎么監(jiān)控

使用 bcc 工具觀測(cè) MySQL：1）dbstat功能：將 MySQL/PostgreSQL 的查詢(xún)延遲匯總為直方圖

語(yǔ)法：

dbstat [-h] [-v] [-p [PID [PID ...]]] [-m THRESHOLD] [-u] [-i INTERVAL] ? ? ? ? ? ? ?{mysql,postgres}

選項(xiàng)：

{mysql,postgres} ? ? ? ? ? ? ? ? ? ? ? ? ? # 觀測(cè)哪種數(shù)據(jù)庫(kù)-h, --help ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? # 顯示幫助然后退出-v, --verbose ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?# 顯示BPF程序-p [PID [PID ...]], --pid [PID [PID ...]] ?# 要觀測(cè)的進(jìn)程號(hào)，空格分隔-m THRESHOLD, --threshold THRESHOLD ? ? ? ?# 只統(tǒng)計(jì)查詢(xún)延遲比此閾值高的-u, --microseconds ? ? ? ? ? ? ? ? ? ? ? ? # 以微秒為時(shí)間單位來(lái)顯示延遲(默認(rèn)單位：毫秒)-i INTERVAL, --interval INTERVAL ? ? ? ? ? # 打印摘要的時(shí)間間隔(單位：秒)

示例：

# 使用 sysbench 在被觀測(cè)數(shù)據(jù)庫(kù)上執(zhí)行 select[root@liuan tools]# dbstat mysql -p `pidof mysqld` -uTracing database queries for pids 3350 slower than 0 ms...^C[14:42:26] ? ? query latency (us)

2）dbslower

功能：跟蹤 MySQL/PostgreSQL 的查詢(xún)時(shí)間高于閾值

語(yǔ)法：

dbslower [-h] [-v] [-p [PID [PID ...]]] [-x PATH] [-m THRESHOLD] ? ? ? ? ? ? ? ? {mysql,postgres}

參數(shù)：

{mysql,postgres} ? ? ? ? ? ? ? ? ? ? ? ? ? # 觀測(cè)哪種數(shù)據(jù)庫(kù) -h, --help ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? # 顯示幫助然后退出 -v, --verbose ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?# 顯示BPF程序 -p [PID [PID ...]], --pid [PID [PID ...]] ?# 要觀測(cè)的進(jìn)程號(hào)，空格分隔 -m THRESHOLD, --threshold THRESHOLD ? ? ? ?# 只統(tǒng)計(jì)查詢(xún)延遲比此閾值高的 -x PATH, --exe PATH ? ? ? ? ? ? ? ? ? ? ? ?# 數(shù)據(jù)庫(kù)二進(jìn)制文件的位置

示例：

# 使用sysbench在被觀測(cè)數(shù)據(jù)庫(kù)上執(zhí)行update_index [root@liuan tools]# dbslower mysql -p `pidof mysqld` -m 2 Tracing database queries for pids 3350 slower than 2 ms... TIME(s) ? ? ? ?PID ? ? ? ? ?MS QUERY 1.765087 ? ? ? 3350 ? ? ?2.996 UPDATE sbtest1 SET k=k+1 WHERE id=963 3.187147 ? ? ? 3350 ? ? ?2.069 UPDATE sbtest1 SET k=k+1 WHERE id=628 5.945987 ? ? ? 3350 ? ? ?2.171 UPDATE sbtest1 SET k=k+1 WHERE id=325 7.771761 ? ? ? 3350 ? ? ?3.853 UPDATE sbtest1 SET k=k+1 WHERE id=5955. 使用限制

bcc 基于 eBPF 開(kāi)發(fā)（需要 Linux 3.15 及更高版本）。bcc 使用的大部分內(nèi)容都需要 Linux 4.1 及更高版本。

"bcc.usdt.USDTException: failed to enable probe 'query__start'; a possible cause can be that the probe requires a pid to enable" 需要 MySQL 具備 Dtrace tracepoint。

名稱(chēng)欄目：mysql主從怎么監(jiān)控 查看mysql主從
網(wǎng)站URL：http://chinadenli.net/article48/hihjhp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站導(dǎo)航、建站公司、網(wǎng)站內(nèi)鏈、云服務(wù)器、用戶(hù)體驗(yàn)、網(wǎng)站排名

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)