mysql資料庫監控
怎樣使用zabbix監控伺服器的mysql資料庫
進入 zabbix web 台Configuration-->Hosts groups-->點擊Create host group-->選擇template選項卡選擇模板TemplateApp MySQLTempldate OS linux點擊update 即（032.png）
進入zabbix web 台configuration-->hosts-->點擊主機 name-->選擇template選
項卡選擇模板Template App MySQL點擊左邊Add按鈕點擊update按鈕即(033.png)
Ⅱ java 監控mysql資料庫
沒有使用這個命令。但是你的想法應該是可以實現的。
你可以嘗試使用 linux 遠程執行命令，把這個列表寫到一個固定文件中。
然後通過遠程讀取該文件的方式獲取的這個列表。
Ⅲ MYSQL如何監控sql腳本
如果是這樣的話，你可以看看關於mysql的觸發器的東西。
Rainbow702 寫道引用最好可以日誌或其它方式記錄下來資料庫本身應該就有操作日誌的啊問題補充：我用的hibernate的PostDeleteEvent,還是有些問題
hibernate自帶的監聽
jkxydp 寫道用spring的aop啊，在刪除記錄的方法上加一個記錄日誌的切入點去記錄啊，層一般增、刪、改、查的方法都是單獨出來的吧，在所有刪除記錄的方法上寫切入點。
或者使用loger，其它的都不寫，就在刪除的方法裡面寫上日誌應該就沒問題。
Ⅳ 如何動態監控mysql binlog
有兩種方法，一種方法使用mysql的check table和repair table 的sql語句，另一種方法是使用MySQL提供的多個myisamchk, isamchk數據檢測恢復工具。前者使用起來比較簡便。推薦使用。
1. check table 和 repair table
登陸mysql 終端：
mysql -uxxxxx -p dbname
check table tabTest;
如果出現的結果說Status是OK，則不用修復，如果有Error，可以用：
repair table tabTest;
進行修復，修復之後可以在用check table命令來進行檢查。在新版本的phpMyAdmin裡面也可以使用check/repair的功能。
2. myisamchk, isamchk
其中myisamchk適用於MYISAM類型的數據表，而isamchk適用於ISAM類型的數據表。這兩條命令的主要參數相同，一般新的系統都使用MYISAM作為預設的數據表類型，這里以myisamchk為例子進行說明。當發現某個數據表出現問題時可以使用：
myisamchk tablename.MYI
進行檢測，如果需要修復的話，可以使用：
myisamchk -of tablename.MYI
關於myisamchk的詳細參數說明，可以參見它的使用幫助。需要注意的時在進行修改時必須確保MySQL伺服器沒有訪問這個數據表，保險的情況下是最好在進行檢測時把MySQL伺服器Shutdown掉。
另外可以把下面的命令放在你的rc.local裡面啟動MySQL伺服器前：
[ -x /tmp/mysql.sock ] && /pathtochk/myisamchk -of /DATA_DIR/*/*.MYI
其中的/tmp/mysql.sock是MySQL監聽的Sock文件位置，對於使用RPM安裝的用戶應該是/var/lib/mysql/mysql.sock，對於使用源碼安裝則是/tmp/mysql.sock可以根據自己的實際情況進行變更，而pathtochk則是myisamchk所在的位置，DATA_DIR是你的MySQL資料庫存放的位置。
需要注意的時，如果你打算把這條命令放在你的rc.local裡面，必須確認在執行這條指令時MySQL伺服器必須沒有啟動！檢測修復所有資料庫(表)
Ⅳ 如何監控MySQL資料庫的數據變化
1、打開資料庫配置文件my.ini （一般在資料庫安裝目錄）（D:\MYSQL）
2、在資料庫的最後一行添加
log=log.txt
代碼
3、重啟mysql資料庫
4、去資料庫數據目錄 我的是(D:\MYSQL\data) 你會發現多了一個log.txt文件
Ⅵ 如何監控mysql表記錄變化
本期我們用 MySQL 提供的 DBUG 工具來研究 MySQL 的 SQL 處理流程。
起手先造個實例
本次實驗中，我們藉助了 MySQL 的 DBUG 包，來讓 MySQL 將處理過程暴露出來。MySQL 中類似的技術還有不少，比如 performance_schema，OPTIMIZER_TRACE 等等。
這些技術將 MySQL 的不同方向的信息暴露出來，方便大家理解其中機制。
Ⅶ java如何對監控Mysql資料庫對象是否出現錯誤
你說的資料庫對象時什麼不太明白。。。
一般做資料庫監控都是定時執行一條簡單的sql就OK了
類似：
select(0)fromtest；
不過這個功能很多有數據源的服務，或者監控系統都實現了。
weblogic、nagios啥的都有這個功能，自己配一下就行。
資料庫監控埠也行，定時telnet
Ⅷ MySQL如何實現高可用
1. 概述
我們在考慮MySQL資料庫的高可用的架構時，主要要考慮如下幾方面：
關於對高可用的分級在這里我們不做詳細的討論，這里只討論常用高可用方案的優缺點以及高可用方案的選型。
2. 高可用方案
2.1. 主從或主主半同步復制
使用雙節點資料庫，搭建單向或者雙向的半同步復制。在5.7以後的版本中，由於lossless replication、logical多線程復制等一些列新特性的引入，使得MySQL原生半同步復制更加可靠。
常見架構如下：
通常會和proxy、keepalived等第三方軟體同時使用，即可以用來監控資料庫的 健康 ，又可以執行一系列管理命令。如果主庫發生故障，切換到備庫後仍然可以繼續使用資料庫。
優點：
缺點：
2.2. 半同步復制優化
半同步復制機制是可靠的。如果半同步復制一直是生效的，那麼便可以認為數據是一致的。但是由於網路波動等一些客觀原因，導致半同步復制發生超時而切換為非同步復制，那麼這時便不能保證數據的一致性。所以盡可能的保證半同步復制，便可提高數據的一致性。
該方案同樣使用雙節點架構，但是在原有半同復制的基礎上做了功能上的優化，使半同步復制的機制變得更加可靠。
可參考的優化方案如下：
半同步復制由於發生超時後，復制斷開，當再次建立起復制時，同時建立兩條通道，其中一條半同步復制通道從當前位置開始復制，保證從機知道當前主機執行的進度。另外一條非同步復制通道開始追補從機落後的數據。當非同步復制通道追趕到半同步復制的起始位置時，恢復半同步復制。
搭建兩條半同步復制通道，其中連接文件伺服器的半同步通道正常情況下不啟用，當主從的半同步復制發生網路問題退化後，啟動與文件伺服器的半同步復制通道。當主從半同步復制恢復後，關閉與文件伺服器的半同步復制通道。
優點：
缺點：
2.3. 高可用架構優化
將雙節點資料庫擴展到多節點資料庫，或者多節點資料庫集群。可以根據自己的需要選擇一主兩從、一主多從或者多主多從的集群。
由於半同步復制，存在接收到一個從機的成功應答即認為半同步復製成功的特性，所以多從半同步復制的可靠性要優於單從半同步復制的可靠性。並且多節點同時宕機的幾率也要小於單節點宕機的幾率，所以多節點架構在一定程度上可以認為高可用性是好於雙節點架構。
但是由於資料庫數量較多，所以需要資料庫管理軟體來保證資料庫的可維護性。可以選擇MMM、MHA或者各個版本的proxy等等。常見方案如下：
MHA Manager會定時探測集群中的master節點，當master出現故障時，它可以自動將最新數據的slave提升為新的master，然後將所有其他的slave重新指向新的master，整個故障轉移過程對應用程序完全透明。
MHA Node運行在每台MySQL伺服器上，主要作用是切換時處理二進制日誌，確保切換盡量少丟數據。
MHA也可以擴展到如下的多節點集群：
優點：
缺點：
Zookeeper使用分布式演算法保證集群數據的一致性，使用zookeeper可以有效的保證proxy的高可用性，可以較好的避免網路分區現象的產生。
優點：
缺點：
2.4. 共享存儲
共享存儲實現了資料庫伺服器和存儲設備的解耦，不同資料庫之間的數據同步不再依賴於MySQL的原生復制功能，而是通過磁碟數據同步的手段，來保證數據的一致性。
SAN的概念是允許存儲設備和處理器（伺服器）之間建立直接的高速網路（與LAN相比）連接，通過這種連接實現數據的集中式存儲。常用架構如下：
使用共享存儲時，MySQL伺服器能夠正常掛載文件系統並操作，如果主庫發生宕機，備庫可以掛載相同的文件系統，保證主庫和備庫使用相同的數據。
優點：
缺點：
DRBD是一種基於軟體、基於網路的塊復制存儲解決方案，主要用於對伺服器之間的磁碟、分區、邏輯卷等進行數據鏡像，當用戶將數據寫入本地磁碟時，還會將數據發送到網路中另一台主機的磁碟上，這樣的本地主機(主節點)與遠程主機(備節點)的數據就可以保證實時同步。常用架構如下：
當本地主機出現問題，遠程主機上還保留著一份相同的數據，可以繼續使用，保證了數據的安全。
DRBD是linux內核模塊實現的快級別的同步復制技術，可以與SAN達到相同的共享存儲效果。
優點：
缺點：
2.5. 分布式協議
分布式協議可以很好解決數據一致性問題。比較常見的方案如下：
MySQL cluster是官方集群的部署方案，通過使用NDB存儲引擎實時備份冗餘數據，實現資料庫的高可用性和數據一致性。
優點：
缺點：
基於Galera的MySQL高可用集群， 是多主數據同步的MySQL集群解決方案，使用簡單，沒有單點故障，可用性高。常見架構如下：
優點：
缺點：
Paxos 演算法解決的問題是一個分布式系統如何就某個值（決議）達成一致。這個演算法被認為是同類演算法中最有效的。Paxos與MySQL相結合可以實現在分布式的MySQL數據的強一致性。常見架構如下：
優點：
缺點：
3. 總結
隨著人們對數據一致性的要求不斷的提高，越來越多的方法被嘗試用來解決分布式數據一致性的問題，如MySQL自身的優化、MySQL集群架構的優化、Paxos、Raft、2PC演算法的引入等等。
而使用分布式演算法用來解決MySQL資料庫數據一致性的問題的方法，也越來越被人們所接受，一系列成熟的產品如PhxSQL、MariaDB Galera Cluster、Percona XtraDB Cluster等越來越多的被大規模使用。
隨著官方MySQL Group Replication的GA，使用分布式協議來解決數據一致性問題已經成為了主流的方向。期望越來越多優秀的解決方案被提出，MySQL高可用問題可以被更好的解決。
分布式解決方案 tidb
多主 多備 master lvs做vip 讀寫分離中間件
Ⅸ 如何監控MySQL
首先介紹下 pt-stalk，它是 Percona-Toolkit 工具包中的一個工具，說起 PT 工具包大家都不陌生，平時常用的 pt-query-digest、 pt-online-schema-change 等工具都是出自於這個工具包，這里就不多介紹了。
pt-stalk 的主要功能是在出現問題時收集 OS 及 MySQL 的診斷信息，這其中包括：
1. OS 層面的 CPU、IO、內存、磁碟、網路等信息；
2. MySQL 層面的行鎖等待、會話連接、主從復制，狀態參數等信息。
而且 pt-stalk 是一個 Shell腳本，對於我這種看不懂 perl 的人來說比較友好，腳本裡面的監控邏輯與監控命令也可以拿來參考，用於構建自己的監控體系。
三、使用
接著我們來看下如何使用這個工具。
pt-stalk 通常以後台服務形式監控 MySQL 並等待觸發條件，當觸發條件時收集相關診斷數據。
觸發條件相關的參數有以下幾個：
function：
∘默認為 status，代表監控 SHOW GLOBAL STATUS 的輸出；
∘也可以設置為 processlist，代表監控 show processlist 的輸出；
variable：
∘默認為 Threads_running，代表 監控參數，根據上述監控輸出指定具體的監控項；
threshold：
∘默認為 25，代表 監控閾值，監控參數超過閾值，則滿足觸發條件；
∘監控參數的值非數字時，需要配合 match 參數一起使用，如 processlist 的 state 列；
cycles：
∘默認為 5，表示連續觀察到五次滿足觸發條件時，才觸發收集；
其他一些重要參數：
iterations：該參數指定 pt-stalk 在觸發收集幾次後退出，默認會一直運行。
run-time：觸發收集後，該參數指定收集多長時間的數據，默認 30 秒。
sleep：該參數指定在觸發收集後，sleep 多久後繼續監控，默認 300 秒。
interval：指定狀態參數的檢查頻率，判斷是否需要觸發收集，默認 1 秒。
dest：監控數據存放路徑，默認為 /var/lib/pt-stalk。
retention-time ：監控數據保留時長，默認 30 天。
daemonize：以後台服務運行，默認不開啟。
log：後台運行日誌，默認為 /var/log/pt-stalk.log。
collect：觸發發生時收集診斷數據，默認開啟。
∘collect-gdb：收集 GDB 堆棧跟蹤，需要 gdb 工具。
∘collect-strace：收集跟蹤數據，需要 strace 工具。
∘collect-tcpmp：收集 tcpmp 數據，需要 tcpmp 工具。
連接參數：host、password、port、socket。
Ⅹ 如何使cacti監控mysql伺服器
cacti監控mysql資料庫的方法
環境：
Cactiez或者cacti主機：192.168.12.5
被監控mysql資料庫主機：192.168.5.231
1. 安裝監控插件
cd /opt
tar -xzvf mysql-cacti-templates-1.1.2.tar.gz
cp /opt/mysql-cacti-templates-1.1.2/ss_get_mysql_stats.php /var/www/html/scripts/
其實裡面我們要監控mysql用到的是：acti_host_template_x_db_server_ht_0.8.6i.xml和mysql_definitions.pl
其他則是監控Apache和Nginx的，接下來我們會介紹到，這里不再詳細的講了。
chown -R apache.apache /var/www/html/scripts
chmod -R 755 /var/www/html/scripts
使用 http 訪問 cacti主機 導入
/opt/mysql-cacti-templates-1.1.2/cacti_host_template_x_db_server_ht_0.8.6i.xml
http://192.168.12.5
默認CactiEZ 和Cacti別是 admin admin
控制台 - 導入導出 - 模板導入 - 瀏覽
選中 cacti_host_template_x_db_server_ht_0.8.6i.xml
保存
2. 配置cacti的mysql插件
修改 ss_get_mysql_stats.php
vi /var/www/html/scripts/ss_get_mysql_stats.php
$mysql_user = 'cacti';
$mysql_pass = 'cacti';
$cache_dir = "/tmp/cacti/cache/";
這個賬戶和密碼是 被監控端主機 給 Cacti主機 授權的 賬戶和密碼
Cacti需要這個賬戶和密碼去連接 被監控機 查詢狀態
mkdir -p /tmp/cacti/cache
chown -R apache.apache /tmp/cacti
chmod -R 755 /tmp/cacti
設置 cacti 緩存目錄在 /tmp/cacti/cache/ 並給予許可權
3. 配置被監控端(192.168.5.231)的mysql 給 cacti 主機授權
mysql -uroot -p
grant process,super on *.* to 'cacti'@'192.168.12.5' identified by 'cacti';
exit
grant process,super on *.* to '賬戶'@'Cacti主機IP地址' identified by '密碼';此命令意義
只允許IP為 192.168.12.5 的主機 以賬戶 cacti 密碼 cacti 去訪問 本機數據
4. 在Cacti主機上(192.168.12.5) 監控Mysql
4.1 為主機添加mysql模塊
控制台 - 管理 - 設備 - 選中之前創建好的主機
然後移到最下面的 添加圖形模版 選中 Mysql相關模塊 然後保存
4.2 為mysql模塊創建圖形
控制台 - 創建 - 創建圖形 - 選中該主機 - 選中mysql模塊 - 創建
4.3 插件mysql性能數據
監視器 - 選中該主機 - 查閱對應的mysql
完畢
-----一些資料庫操作語句
mysqld_safe --user=mysql &
mysql -uroot -p
mysql -uroot -proot
grant ALL PRIVILEGES ON *.* to 『root』@"%" identified by "root" WITH GRANT OPTION;
exit
grant select,insert,update,delete on cacti.* to 『cacti』@」*」identified by "cacti";
exit
grant process,super on *.* to 'cacti'@'%' identified by 'cacti';
grant all privileges on cacti.* to 『cacti』@"%" identified by "cacti";
客戶端開啟Cacti訪問本機mysql的許可權
grant process,super on *.* to 'cacti'@'192.168.12.5' identified by 'cacti';
grant process,super on *.* to 'cacti'@'192.168.5.231' identified by 'cacti';
= = = = =
mysql -ucacti -pcacti -h 192.168.5.231