本文目錄一覽：
MySQL數據庫服務器逐漸變慢分析與解決方法分享
一、檢查系統的狀態
通過操作系統的一些工具檢查系統的狀態，比如CPU、內存、交換、磁盤的利用率，根據經驗或與系統正常時的狀態相比對，有時系統表面上看起來看空閑，這也可能不是一個正常的狀態，因為cpu可能正等待IO的完成。除此之外，還應觀注那些佔用系統資源(cpu、內存)的進程。
1.使用sar來檢查操作系統是否存在IO問題
#sar-u210—
即每隔2秒檢察一次，共執行20次。
結果示例：
註：在redhat下，%system就是所謂的%wio。
Linux2.4.21-20.ELsmp
(YY075)05/19/2005
10:36:07AMCPU%user%nice%system%idle
10:36:09AMall0.000.000.1399.87
10:36:11AMall0.000.000.00100.00
10:36:13AMall0.250.000.2599.49
10:36:15AMall0.130.000.1399.75
10:36:17AMall0.000.000.00100.00
其中：
%usr指的是用戶進程使用的cpu資源的百分比;
%sys指的是系統資源使用cpu資源的百分比;
%wio指的是等待io完成的百分比，這是值得觀注的一項;
%idle即空閑的百分比。
如果wio列的值很大，如在35%以上，說明系統的IO存在瓶頸，CPU花費了很大的時間去等待I/O的完成。Idle很小說明系統CPU很忙。像以上的示例，可以看到wio平均值為11，說明I/O沒什麼特別的問題，而idle值為零，說明cpu已經滿負荷運行了。
2.使用vmstat監控內存
cpu資源
[root@mysql1
~]#
vmstat
procs
———–memory———-—swap–
—–io—-–system–
—–cpu——
r
b
swpd
free
buff
cache
si
so
bi
bo
in
cs
us
sy
id
wa
st
72
25428
54712672264
14
43
53
59
1
198
vmstat
的輸出那些信息值得關注?
io
bo:
磁盤寫的數據量稍大，如果是大文件的寫，10M以內基本不用擔心，如果是小文件寫2M以內基本正常
①
CPU問題
下面幾列需要被察看，以確定cpu是否有問題
Processesinthe
run
queue
(procs
r)
Usertime
(cpu
us)
System
time
(cpu
sy)
Idle
time
(cpu
id)
問題情況:
如果processes
in
run
queue
(procs
r)的數量遠大於系統中cpu的數量，將會使系統便慢。
如果這個數量是cpu的4倍的話，說明系統正面臨cpu能力短缺,這將使系統運行速度大幅度降低
如果cpu的idle時間經常為0的話，或者系統佔用時間(cpu
sy)是用戶佔用時間(cpu
us)兩輩的話，系統面臨缺少cpu資源
解決方案
:
解決這些情況，涉及到調整應用程序，使其能更有效的使用cpu，同時增加cpu的能力或數量
②內存問題
主要查看頁導入的數值(swap中的si)，如果該值比較大就要考慮內存，大概方法如下：
最簡單的，加大RAM
減少RAM的需求
3.磁盤IO問題
處理方式：做raid10提高性能
4.網絡問題
telnet一下MySQL對外開放的端口，如果不通的話，看看防火牆是否正確設置了。另外，看看MySQL是不是開啟了skip-networking的選項，如果開啟請關閉。
怎樣解決MySQL數據庫主從複製延遲的問題
在主服務器上建立一個為從服務器進行複製使用的用戶。該賬戶必須授予 REPLICATION SLAVE 權限，由於僅僅是進行複製使用所以不需要再授予任何其它權限。
mysql GRANT REPLICATION SLAVE ON *.* TO ‘replication’@’%’192.168.0.2’ IDENTIFIED BY ‘slavepasswd’;
mysql FLUSH PRIVILEGES;
3、編輯主服務器的配置文件：/etc/my.cnf的[ mysqld ] 部分：
server-id = 本機數據庫 ID 標示，該部分還應有一個server-id=Master_id選項，其中master_id必須為1到232之間的一個正整數值
log-bin = 二進制日誌的位置和名稱
binlog-do-db = 需要備份的數據庫名，如果備份多個數據庫，重複設置這個選項即可
binlog-ignore-db = 不需要備份的數據庫苦命，如果備份多個數據庫，重複設置這個選項即可
關於MYSQL服務器突然變慢的問題
MySQL 在崩潰恢復時，會遍歷打開所有 ibd 文件的 header page 驗證數據字典的準確性，如果 MySQL 中包含了大量表，這個校驗過程就會比較耗時。 MySQL 下崩潰恢復確實和表數量有關，表總數越大，崩潰恢復時間越長。另外磁盤 IOPS 也會影響崩潰恢復時間，像這裡開發庫的 HDD IOPS 較低，因此面對大量的表空間，校驗速度就非常緩慢。另外一個發現，MySQL 8 下正常啟用時居然也會進行表空間校驗，而故障恢復時則會額外再進行一次表空間校驗，等於校驗了 2 遍。不過 MySQL 8.0 里多了一個特性，即表數量超過 5W 時，會啟用多線程掃描，加快表空間校驗過程。
如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復時的表空間校驗過程嘛？查閱了資料，方法主要有兩種：
配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那麼 validate = false，即可以跳過表空間校驗。實際測試的時候設置 innodb_force_recovery =1，也就是強制恢復跳過壞頁，就可以跳過校驗，然後重啟就是正常啟動了。通過這種臨時方式可以避免崩潰恢復後非常耗時的表空間校驗過程，快速啟動 MySQL，個人目前暫時未發現有什麼隱患。
2. 使用共享表空間替代獨立表空間這樣就不需要打開 N 個 ibd 文件了，只需要打開一個 ibdata 文件即可，大大節省了校驗時間。自從聽了姜老師講過使用共享表空間替代獨立表空間解決 drop 大表時性能抖動的原理後，感覺共享表空間在很多業務環境下，反而更有優勢。
臨時冒出另外一種解決想法，即用 GDB 調試崩潰恢復，通過臨時修改 validate 變量值讓 MySQL 跳過表空間驗證過程，然後讓 MySQL 正常關閉，重新啟動就可以正常啟動了。但是實際測試發現，如果以 debug 模式運行，確實可以臨時修改 validate 變量，跳過表空間驗證過程，但是 debug 模式下代碼運行效率大打折扣，反而耗時更長。而以非 debug 模式運行，則無法修改 validate 變量，想法破滅。
MySQL數據庫服務器逐漸變慢 該如何分析與解決
MySQL 在崩潰恢復時，會遍歷打開所有 ibd 文件的 header page 驗證數據字典的準確性，如果 MySQL 中包含了大量表，這個校驗過程就會比較耗時。 MySQL 下崩潰恢復確實和表數量有關，表總數越大，崩潰恢復時間越長。另外磁盤 IOPS 也會影響崩潰恢復時間，像這裡開發庫的 HDD IOPS 較低，因此面對大量的表空間，校驗速度就非常緩慢。另外一個發現，MySQL 8 下正常啟用時居然也會進行表空間校驗，而故障恢復時則會額外再進行一次表空間校驗，等於校驗了 2 遍。不過 MySQL 8.0 里多了一個特性，即表數量超過 5W 時，會啟用多線程掃描，加快表空間校驗過程。
如何跳過校驗MySQL 5.7 下有方法可以跳過崩潰恢復時的表空間校驗過程嘛？查閱了資料，方法主要有兩種：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那麼 validate = false，即可以跳過表空間校驗。實際測試的時候設置 innodb_force_recovery =1，也就是強制恢復跳過壞頁，就可以跳過校驗，然後重啟就是正常啟動了。通過這種臨時方式可以避免崩潰恢復後非常耗時的表空間校驗過程，快速啟動 MySQL，個人目前暫時未發現有什麼隱患。2. 使用共享表空間替代獨立表空間這樣就不需要打開 N 個 ibd 文件了，只需要打開一個 ibdata 文件即可，大大節省了校驗時間。自從聽了姜老師講過使用共享表空間替代獨立表空間解決 drop 大表時性能抖動的原理後，感覺共享表空間在很多業務環境下，反而更有優勢。
臨時冒出另外一種解決想法，即用 GDB 調試崩潰恢復，通過臨時修改 validate 變量值讓 MySQL 跳過表空間驗證過程，然後讓 MySQL 正常關閉，重新啟動就可以正常啟動了。但是實際測試發現，如果以 debug 模式運行，確實可以臨時修改 validate 變量，跳過表空間驗證過程，但是 debug 模式下代碼運行效率大打折扣，反而耗時更長。而以非 debug 模式運行，則無法修改 validate 變量，想法破滅。
原創文章，作者：XZ0TE，如若轉載，請註明出處：https://www.506064.com/zh-hk/n/128854.html
微信掃一掃 
支付寶掃一掃 