mysql服務器監控

對於任何系統來講，監控都是重要的組成部分。數據庫是一切系統的核心組件，數據庫的穩定性從必定程度上決定了系統的穩定性，因此，對於數據庫的監控，就顯得尤其重要了。常見的開源監控軟件有 Nagios、Zabbix。這些監控軟件，或是提供了數據庫監控插件，或是容許用戶以插件的形式開發本身對數據庫的監控腳本，而且支持的腳本語言也是多種多樣的，用戶徹底能夠按照本身的習慣，來選擇本身的監控軟件，以及編寫適合本身的監控腳本。

本篇主要關注 MySQL 數據庫咱們都要監控些什麼？和怎麼對這些要監控的資源進行監控？

瞭解了這些以後，無論使用任何監控軟件，均可以本身完成對 MySQL 腳本的開發與部署。

對於 MySQL 來講，最基本的監控應該包含如下內容：

對數據庫服務可用性進行監控（經過網絡鏈接到數據庫而且肯定數據庫是能夠對外提供服務的）；
對數據庫性能進行監控（QPS、TPS、併發線程數量的監控）；
對主從複製進行監控（主從複製鏈路狀態的監控、主從複製延遲的監控、按期的確認主從複製的數據是否一致）；
對服務器資源的監控（磁盤空間的監控（不管是數據目錄仍是日誌目錄的空間被佔滿，都會致使 MySQL 不可用）、CPU 的使用狀況、內存的使用狀況、Swap 分區的使用狀況以及網絡 IO 的狀況等）；
1.數據可用性監控
首先咱們先來看下如何確認數據庫是否能夠經過網絡進行鏈接。使用 MySQL 的本地的 SQL 文件鏈接數據庫服務器，並不意味着能夠經過網絡 TCP/IP 協議能鏈接到 MySQL。確認數據庫是否能夠經過網絡進行鏈接，一般使用如下幾種方式中的一種：

方案一：利用 mysqladmin -umonitor_user -p -h ping 命令在遠程服務器上執行，來確認被監控的服務器是否能夠鏈接；
方案二：利用 telnet ip db_port 命令手動確認被監控的服務器是否能夠鏈接；
方案三：使用程序經過網絡創建數據庫鏈接來確認被監控的服務器是否能夠鏈接，這是最好的方式。
能夠鏈接到數據庫並不表明數據庫就是可用的，因此還須要確認數據庫是否能夠讀寫。

如何確認數據庫是否可讀寫？

按期檢查主數據庫的 read_only 參數是否爲 off；
創建監控表並對錶中數據進行更改；
若是隻是監控數據庫是否可讀只須要執行簡單的查詢 select @@version；
能夠鏈接到MySQL 的線程數是有限制的，如何監控數據庫的鏈接數？

show variables like 'max_connections'; //獲取MySQL能接受最大鏈接數的數量
show global status like 'Threads_connected'; //獲取系統變量Threads_connected的值，記錄了當前數據庫的鏈接數量

例如報警就能夠當 Threads_connected / max_connections > 0.8 時，就須要報警。

2.數據性能監控
性能監控不一樣於可用性監控，性能監控更關注的是數據庫性能的變化趨勢，因此在進行性能監控的腳本開發時，就須要注意記錄好性能監控過程當中所採集到的數據庫的狀態信息，以便分析數據庫性能變化趨勢時使用。

對於性能監控來講，可能關注最多的就是 QPS 和 TPS。

QPS = (Queries2 - Queries1) / (Uptime_since_flush_status2 - Uptime_since_flush_status1)

TPS = ((Com_insert2 + Com_update2 + Com_delete2) - (Com_insert1+ Com_update1 + Com_delete1)) /
(Uptime_since_flush_status2 - Uptime_since_flush_status1)

這幾個參數獲取方式：

show global status like 'Queries'
show global status like 'Uptime_since_flush_status'
show global status like 'Com_insert'
show global status like 'Com_update'
show global status like 'Com_delete'

如何監控數據庫的併發請求數量？

一般狀況下，數據庫系統的性能會隨着併發處理請求數量的增長而降低。因此併發請求數量一般還須要和 CPU 的使用率等指標結合起來分析。

數據庫當前併發請求數量能夠經過 show global status like ‘Threads_running’ 獲取。併發處理的數量一般會遠小於同一時間鏈接到數據庫的線程的數量。

一般狀況下併發請求數量是很穩定的，若是咱們發現某一時刻併發量忽然間增大，那麼就須要檢查是否出現了數據庫的異常，好比數據庫出現大量阻塞的狀況下，就頗有可能出現這種現象。

如何監控 InnoDB 的阻塞？

查詢阻塞時間超過 20 秒的 SQL：

SELECT b.trx_mysql_thread_id AS '被阻塞線程'
,b.trx_query AS '被阻塞SQL'
,c.trx_mysql_thread_id AS '阻塞線程'
,c.trx_query AS '阻塞SQL'
,(UNIX_TIMESTAMP()-UNIX_TIMESTAMP(c.trx_started)) AS '阻塞時間'
FROM information_schema.innodb_lock_waits a
JOIN information_schema.innodb_trx b ON a.requesting_trx_id=b.trx_id
JOIN information_schema.innodb_trx c ON a.blocking_trx_id=c.trx_id
WHERE (UNIX_TIMESTAMP()-UNIX_TIMESTAMP(c.trx_started))>20

3.主從複製監控
若是在咱們的數據庫架構中，大量依賴於 MySQL 的主從複製機制的話，那麼主從複製的監控也就成了必不可少的部分了。

如何監控主從複製鏈路的狀態？

對於主從複製的監控，基本都要依賴於 show slave status 命令。

如何監控主從複製延遲？

參與複製的主從服務器之間必定存在着一些延遲，正常的狀況下延遲是很是小的，基本在 1 秒以內。因此對於應用來講，影響並不大，特別是對於一些主從延遲不敏感的應用。若是因爲某種緣由，主從服務器之間出現了很大的延遲，就會影響到應用的正常使用了。因此必需要對主從複製延遲進行一些監控。

若是發現從服務器之間的延遲持續的增大，那麼就須要進行一些檢查，查找緣由並及時解決。通常狀況下，能夠經過下面的方法對主從複製延遲進行監控：

利用 show slave status 命令返回的信息：

Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 0
_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0

Seconds_Behind_Master 就是主從複製延遲的秒數。這種獲取方法比較簡單，可是結果並不許確，由於這個值是根據同步到從服務器上主服務器的 binlog 和已經在從服務器上從新執行過的 binlog 日誌之間的時間差，因此會有不少種狀況會致使數據不許確，例如當網絡出現問題的時候，主服務器上還有大量的 binlog 沒有同步到從服務器上，同時已經同步到從服務器上的 binlog 都已經被徹底被重用完了，這種狀況下，主從之間是存在着很大的延遲的，可是經過 show slave status 命令卻不能發現這種延遲。

因此爲了更加準確的發現延遲，就須要另外的方法：

這個方法須要使用多線程的程序同時對於主從服務器的狀態來進行檢查。主服務器上執行 show master status 命令來獲取主服務器上的二進制日誌文件信息和偏移量：

mysql> show master status \G
***************************** 1. row *****************************
File: mysql-bin.001099
Position: 302055050

從服務器上執行 show slave status 命令獲取主服務器發送過來的二進制日誌文件信息和偏移量：

Master_Log_File: mysql-bin.001099
Read_Master_Log_Pos: 301855050

以及在從服務器上執行 show slave status 命令獲取已經傳輸完成的主服務器上二進制文件的信息和偏移量：

Exec_Master_Log_Pos: 301855050
Relay_Log_Space: 301855350

經過上面三個信息的對比，就能夠知道主從服務器之間是否存在大量的延遲了。若是文件名（File 和 Master_Log_File）和偏移量（Position 和 Read_Master_Log_Pos）都同樣，說明當前的主從不存在任何延遲的。

當每次修復完主從複製的時候，都要檢查主從複製數據的一致性。那麼如何驗證主從複製的數據是否一致？

這裏就須要使用到 Percona 公司發佈的 MySQL 工具集中的 pt-table-checksum：

pt-table-checksum u=db_user,p='db_password' \
--databases mysql \
--replicate test.checksums

–databases 參數指定的是數據庫的名字，–replicate 參數指定的是要在 test 庫下建立 checksums 這張表，而且將數據寫入到這張檢測表中。須要注意的是，這條命令只須要在主庫上運行就能夠了，它會自動發現主庫下全部從庫信息，並對全部從庫指定的數據庫的數據來進行檢測。

創建數據庫帳戶可使用：

GRANT SELECT,PROCESS,SUPER,REPLICATION SLAVE ON *.* TO 'db_user'@'ip' IDENTIFIED BY 'db_passwor