建站
咨詢
售后
建站咨詢
新聞中心
作為一個(gè)數(shù)據(jù)庫(kù)管理員，掌握數(shù)據(jù)庫(kù)增長(zhǎng)的趨勢(shì)和規(guī)律是至關(guān)重要的。監(jiān)測(cè)數(shù)據(jù)庫(kù)增長(zhǎng)可以幫助你及時(shí)預(yù)測(cè)和解決可能出現(xiàn)的容量問(wèn)題，保證數(shù)據(jù)庫(kù)的正常運(yùn)行，避免數(shù)據(jù)丟失和性能下降。那么如何有效地監(jiān)測(cè)數(shù)據(jù)庫(kù)增長(zhǎng)呢？本文將介紹一些有效的方法和工具，希望對(duì)你有所幫助。
1、使用監(jiān)測(cè)工具
市面上有很多數(shù)據(jù)庫(kù)監(jiān)測(cè)工具，如Oracle、SQL Server、MySQL等都提供了自己的監(jiān)測(cè)工具，而且這些工具不需要多少額外的配置就能夠使用。這些工具提供了一些簡(jiǎn)單易用的監(jiān)測(cè)指標(biāo)，如數(shù)據(jù)庫(kù)文件大小、文件分布、日志文件大小等。通過(guò)這些指標(biāo)，我們可以了解數(shù)據(jù)庫(kù)所占用的磁盤(pán)區(qū)域情況，及時(shí)解決可能出現(xiàn)的磁盤(pán)空間不足的問(wèn)題。
此外，一些第三方數(shù)據(jù)庫(kù)監(jiān)測(cè)工具如Solarwinds、Nagios、Zabbix等也是非常不錯(cuò)的選擇，它們不僅能夠監(jiān)測(cè)數(shù)據(jù)庫(kù)的磁盤(pán)空間使用情況，還能夠監(jiān)測(cè)數(shù)據(jù)庫(kù)的CPU利用率、內(nèi)存利用率、網(wǎng)絡(luò)流量等指標(biāo)，幫助管理員全面掌握數(shù)據(jù)庫(kù)的性能情況。
2、定期收集信息
除了使用監(jiān)測(cè)工具外，定期收集數(shù)據(jù)庫(kù)信息也是一個(gè)不錯(cuò)的選擇。管理員可以使用SQL語(yǔ)句收集數(shù)據(jù)庫(kù)中的數(shù)據(jù)大小、表大小、索引大小、歷史日志等信息，這些信息可以通過(guò)一個(gè)簡(jiǎn)單的腳本定期收集并保存到一個(gè)文件中。通過(guò)這些數(shù)據(jù)可以了解數(shù)據(jù)庫(kù)的增長(zhǎng)趨勢(shì)、表中的數(shù)據(jù)增長(zhǎng)速度、索引的增長(zhǎng)情況等，掌握隨時(shí)間變化的數(shù)據(jù)庫(kù)情況。
此外，在進(jìn)行定期收集信息時(shí)，管理員還應(yīng)該注意一些相關(guān)的指標(biāo)，如磁盤(pán)空間、CPU利用率、內(nèi)存使用情況等，這些指標(biāo)能夠幫助管理員協(xié)助管理磁盤(pán)和系統(tǒng)資源的使用情況，及時(shí)預(yù)測(cè)和解決問(wèn)題。
3、分析歷史數(shù)據(jù)
通過(guò)分析數(shù)據(jù)庫(kù)的歷史數(shù)據(jù)，可以預(yù)測(cè)未來(lái)數(shù)據(jù)增長(zhǎng)的趨勢(shì)。管理員可以制定一個(gè)計(jì)劃，每隔一段時(shí)間對(duì)數(shù)據(jù)庫(kù)的歷史數(shù)據(jù)進(jìn)行一次分析，從中找出一些規(guī)律和趨勢(shì)。通過(guò)這些規(guī)律和趨勢(shì)，管理員就能夠有效地預(yù)測(cè)未來(lái)數(shù)據(jù)庫(kù)的增長(zhǎng)速度，避免因未來(lái)高速增長(zhǎng)而引起的數(shù)據(jù)庫(kù)擴(kuò)容問(wèn)題。此外，當(dāng)數(shù)據(jù)庫(kù)出現(xiàn)異常增長(zhǎng)時(shí)，管理員也能夠及時(shí)作出反應(yīng)，減少影響和損失。
4、自動(dòng)化監(jiān)測(cè)
通過(guò)自動(dòng)化監(jiān)測(cè)，管理員可以讓數(shù)據(jù)庫(kù)管理更加高效和精準(zhǔn)。自動(dòng)化工具可以周期性地檢測(cè)數(shù)據(jù)庫(kù)文件大小、數(shù)據(jù)庫(kù)表大小、索引大小等信息。當(dāng)某個(gè)指標(biāo)達(dá)到預(yù)定的閾值時(shí)，管理員可以立即收到警報(bào)，及時(shí)進(jìn)行擴(kuò)容和優(yōu)化處理，減少事故發(fā)生的可能性。此外，管理員還可以設(shè)置警報(bào)規(guī)則，使自動(dòng)化監(jiān)測(cè)更加智能化。
以上介紹了一些有效的數(shù)據(jù)庫(kù)監(jiān)測(cè)方法和工具，管理員可以根據(jù)自己的需求和經(jīng)驗(yàn)選擇合適的方法進(jìn)行監(jiān)測(cè)。不過(guò)要注意，數(shù)據(jù)庫(kù)監(jiān)測(cè)不是一次性的工作，而是需要長(zhǎng)期的關(guān)注和維護(hù)。只有管理員能夠切實(shí)地將監(jiān)測(cè)工作落實(shí)到位，才能及時(shí)發(fā)現(xiàn)問(wèn)題、解決問(wèn)題，確保數(shù)據(jù)庫(kù)的長(zhǎng)期穩(wěn)定運(yùn)行。
成都網(wǎng)站建設(shè)公司-創(chuàng)新互聯(lián),建站經(jīng)驗(yàn)豐富以策略為先導(dǎo)10多年以來(lái)專注數(shù)字化網(wǎng)站建設(shè),提供企業(yè)網(wǎng)站建設(shè),高端網(wǎng)站設(shè)計(jì),響應(yīng)式網(wǎng)站制作,設(shè)計(jì)師量身打造品牌風(fēng)格,熱線:028-86922220如何查看數(shù)據(jù)庫(kù)中的數(shù)據(jù)
數(shù)據(jù)庫(kù)一般查看數(shù)據(jù)的話有兩種：
1.
利用SQL的SELECT語(yǔ)句；
2.
通過(guò)圖形命令的查詢按鈕。
當(dāng)然你將數(shù)據(jù)導(dǎo)出，漏梁慎當(dāng)然返敬渣族也是可以的。導(dǎo)出，可以直接導(dǎo)出的目錄，還可以指定導(dǎo)出的文件類型。
如何查看mysql數(shù)據(jù)庫(kù)并況
1.mysql> show status like ‘Threads%’;
+—–++
| Variable_name | Value |
+—–++
| Threads_cached ||
| Threads_connected || ###這個(gè)數(shù)值指的是打開(kāi)的連接數(shù)
| Threads_created ||
| Threads_running || ###這個(gè)數(shù)值指的是激活的連接數(shù)，這個(gè)數(shù)值一般遠(yuǎn)低于connected數(shù)值
+—–++
Threads_connected 跟show processlist結(jié)果相同，表示當(dāng)前連接數(shù)。準(zhǔn)確的來(lái)說(shuō)，Threads_running是代表當(dāng)前并發(fā)數(shù)
這是是查詢數(shù)據(jù)庫(kù)當(dāng)前設(shè)置的更大連接數(shù)
2.mysql> show variables like ‘%max_connections%’;
+—++
| Variable_name | Value |
+—++
| max_connections ||
+—++
可以在/etc/my.cnf里面設(shè)置數(shù)據(jù)庫(kù)的更大連接數(shù)
max_connections = 1000
max_connections 參數(shù)可以用于控制數(shù)據(jù)庫(kù)的更大虧缺慶連接數(shù)：
3.mysql> show variables like ‘%connect%’;
++—–+
| Variable_name| Value|
++—–+
| character_set_connection | latin|
| collation_connection | latin1_swedish_ci |
| connect_timeout| |
| init_connect| |
| max_connect_errors| |
| max_connections| |
| max_user_connections | |
++—–+
很多開(kāi)發(fā)人員都會(huì)遇見(jiàn)”MySQL: ERROR 1040: Too many connections”的異常情況，造扮升成這種情況的一種原因是訪問(wèn)量過(guò)銷握高，MySQL服務(wù)器抗不住，這個(gè)時(shí)候就要考慮增加從服務(wù)器分散讀壓力；另一種原因就是MySQL配置文件中max_connections值過(guò)小。
首先，我們來(lái)查看mysql的更大連接數(shù)：
mysql> show variables like ‘%max_connections%’;+—++| Variable_name | Value |+—++| max_connections | 151 |+—++1 row in set (0.00 sec)
其次，查看服務(wù)器響應(yīng)的更大連接數(shù):
mysql> show global status like ‘Max_used_connections’;
+++| Variable_name | Value |+++| Max_used_connections | 2 |+++1 row in set (0.00 sec)
可以看到服務(wù)器響應(yīng)的更大連接數(shù)為2，遠(yuǎn)遠(yuǎn)低于mysql服務(wù)器允許的更大連接數(shù)值。
對(duì)于mysql服務(wù)器更大連接數(shù)值的設(shè)置范圍比較理想的是：服務(wù)器響應(yīng)的更大連接數(shù)值占服務(wù)器上限連接數(shù)值的比例值在10%以上，如果在10%以下，說(shuō)明mysql服務(wù)器更大連接上限值設(shè)置過(guò)高。
Max_used_connections / max_connections * 100% = 2/151 *100% ≈ 1%
我們可以看到占比遠(yuǎn)低于10%（因?yàn)檫@是本地測(cè)試服務(wù)器，結(jié)果值沒(méi)有太大的參考意義，大家可以根據(jù)實(shí)際情況設(shè)置連接數(shù)的上限值）。
再來(lái)看一下自己 linode VPS 現(xiàn)在（時(shí)間：：40：11）的結(jié)果值：
mysql> show variables like ‘%max_connections%’;
+—++| Variable_name | Value |+—++| max_connections | 151 |+—++1 row in set (0.19 sec)mysql> show global status like ‘Max_used_connections’;+++| Variable_name | Value |+++| Max_used_connections | 44 |+++1 row in set (0.17 sec)
這里的更大連接數(shù)占上限連接數(shù)的30％左右。
上面我們知道怎么查看mysql服務(wù)器的更大連接數(shù)值，并且知道了如何判斷該值是否合理，下面我們就來(lái)介紹一下如何設(shè)置這個(gè)更大連接數(shù)值。
方法1：
mysql> set GLOBAL max_connections=256;Query OK, 0 rows affected (0.00 sec)mysql> show variables like ‘%max_connections%’;+—++| Variable_name | Value |+—++| max_connections | 256 |+—++1 row in set (0.00 sec)
方法2：
修改mysql配置文件my.cnf，在段中添加或修改max_connections值：
max_connections=128
重啟mysql服務(wù)即可。
下載個(gè)mysql性能監(jiān)視器可以的
現(xiàn)象
Syench對(duì)MySQL進(jìn)行壓測(cè), 并發(fā)數(shù)過(guò)大(>5k)時(shí), Syench建立連接的步驟會(huì)超時(shí).
猜想
猜想: 直覺(jué)上這很簡(jiǎn)單, Syench每建立一個(gè)連接, 都要消耗一個(gè)線程, 資源消耗過(guò)大導(dǎo)致超時(shí).
驗(yàn)證: 修改Syench源碼, 調(diào)大超時(shí)時(shí)間, 仍然會(huì)發(fā)生超時(shí).
檢查環(huán)境
猜想失敗, 回到常規(guī)的環(huán)境檢查:
MySQL error log 未見(jiàn)異常.
syslog 未見(jiàn)異常.
tcpdump 觀察網(wǎng)絡(luò)包未見(jiàn)異常, 連接能完成正常的三次握手; 只觀察到在出問(wèn)題的連接中, 有一部分的TCP握手的之一個(gè)SYN包發(fā)生了重傳, 另一梁轎迅部分沒(méi)有發(fā)生重傳.
自己寫(xiě)一個(gè)簡(jiǎn)單的并發(fā)發(fā)生器, 替換syench, 可重現(xiàn)場(chǎng)景. 排除syench的影響
猜想2
懷疑 MySQL 在應(yīng)用層因?yàn)槟撤N原因, 沒(méi)有發(fā)送握手包, 比如卡在某一個(gè)流程上:
檢查MySQL堆棧未見(jiàn)異常, 仿佛MySQL在應(yīng)用層沒(méi)有看到新連接進(jìn)入.
通過(guò)strace檢查MySQL, 發(fā)現(xiàn) accept() 調(diào)用確實(shí)沒(méi)有感知到新連接.
懷疑是OS的原因, Google之, 得到參考文檔: A TCP “stuck” connection mystery【
分析
參考文檔中的現(xiàn)象跟目前的狀況很類似, 簡(jiǎn)述如下:
正常的TCP連接流程:
Client 向 Server 發(fā)起連接請(qǐng)求, 發(fā)送SYN.
Server 預(yù)留連接資源, 向 Client 回復(fù)SYN-ACK.
Client 向 Server 回復(fù)ACK.
Server 收到 ACK, 連接建立.
在業(yè)務(wù)層上, Client和Server間進(jìn)行通訊.
當(dāng)發(fā)生類似SYN-flood的現(xiàn)象時(shí), TCP連接的流程會(huì)使用SYN-cookie, 變?yōu)?
Client 向 Server 發(fā)起連接請(qǐng)求, 發(fā)送SYN.
Server 不預(yù)留連接資源, 向 Client 回復(fù)SYN-ACK, 包中附帶有帆陪簽名A.
Client 向 Server 回復(fù)ACK, 附帶 f(簽名A) (對(duì)簽名進(jìn)行運(yùn)算的結(jié)果).
Server 驗(yàn)證簽名, 分配連接資源, 連接建立.
在業(yè)務(wù)層上, Client和Server間進(jìn)行通訊.
當(dāng)啟用SYN-cookie時(shí), 第3步的ACK包因?yàn)?nbsp;某種原因 丟失, 那么:
從Client的視角, 連接已經(jīng)建立.
從Server的視角, 連接并不存在, 既沒(méi)有建立, 也沒(méi)有”即將建立” (若不啟用SYN-cookie, Server會(huì)知道某個(gè)連接”即將建立”)
發(fā)生這種情況時(shí):
若業(yè)務(wù)層的之一個(gè)包應(yīng)是從 Client 發(fā)往 Server, 則會(huì)進(jìn)行重發(fā)或拋出連接錯(cuò)誤
若業(yè)務(wù)層的之一個(gè)包應(yīng)是從 Server 發(fā)往 Client的, Server不會(huì)發(fā)出之一個(gè)包. MySQL的故障就屬于這種情況.
TCP握手的第三步ACK包為什么丟失
參考文檔中, 對(duì)于TCP握手的第三橡此步ACK包的丟失原因, 描述為:
Some of these packets get lost because some buffer somewhere overflows.
我們可以通過(guò)Systemtap進(jìn)一步探究原因. 通過(guò)一個(gè)簡(jiǎn)單的腳本:
probe kernel.function(“cookie_v4_check”).return
{
source_port = @cast($skb->head + $skb->transport_header, “struct tcphdr”)->source
printf(“source=%d, return=%d\n”,readable_port(source_port), $return)
}
function readable_port(port) {
return (port & ((1> 8)
}
觀察結(jié)果, 可以確認(rèn)cookie_v4_check (syn cookie機(jī)制進(jìn)行包簽名檢查的函數(shù))會(huì)返回 NULL(0). 即驗(yàn)證是由于syn cookie驗(yàn)證不通過(guò), 導(dǎo)致TCP握手的第三步ACK包不被接受.
之后就是對(duì)其中不同條件進(jìn)行觀察, 看看是哪個(gè)條件不通過(guò). 最終原因是accept隊(duì)列滿(sk_acceptq_is_full):
static inline bool sk_acceptq_is_full(const struct sock *sk){ return sk->sk_ack_backlog > sk- >sk_max_ack_backlog;}
恢復(fù)故障與日志的正關(guān)聯(lián)
在故障處理的一開(kāi)始, 我們就檢查了syslog, 結(jié)論是未見(jiàn)異常.
當(dāng)整個(gè)故障分析完成, 得知了故障與syn cookie有關(guān), 回頭看syslog, 里面是有相關(guān)的信息, 只是和故障發(fā)生的時(shí)間不匹配, 沒(méi)有正關(guān)聯(lián), 因此被忽略.
檢查L(zhǎng)inux源碼:
if (!queue->synflood_warned &&
sysctl_tcp_syncookies != 2 &&
xchg(&queue->synflood_warned, 1) == 0)
pr_info(“%s: Possible SYN flooding on port %d. %s.
Check SNMP counters.\n”,
proto, ntohs(tcp_hdr(skb)->dest), msg);
可以看到日志受到了抑制, 因此日志與故障的正關(guān)聯(lián)被破壞.
粗看源碼, 每個(gè)listen socket只會(huì)發(fā)送一次告警日志, 要獲得日志與故障的正關(guān)聯(lián), 必須每次測(cè)試重啟MySQL.
解決方案
這種故障一旦形成, 難以檢測(cè); 系統(tǒng)日志中只會(huì)出現(xiàn)一次, 在下次重啟MySQL之前就不會(huì)再出現(xiàn)了; Client如果沒(méi)有合適的超時(shí)機(jī)制, 萬(wàn)劫不復(fù).
解決方案:
1. 修改MySQL的協(xié)議, 讓Client先發(fā)握手包. 顯然不現(xiàn)實(shí).
2. 關(guān)閉syn_cookie. 有安全的人又要跳出來(lái)了.
3. 或者調(diào)高syn_cookie的觸發(fā)條件 (syn backlog長(zhǎng)度). 降低系統(tǒng)對(duì)syn flood的敏感度, 使之可以容忍業(yè)務(wù)的syn波動(dòng).
有多個(gè)系統(tǒng)參數(shù)混合影響syn backlog長(zhǎng)度, 參看【
下圖為精華總結(jié)
請(qǐng)點(diǎn)擊輸入圖片描述
關(guān)于查看數(shù)據(jù)庫(kù)數(shù)據(jù)增長(zhǎng)情況的介紹到此就結(jié)束了，不知道你從中找到你需要的信息了嗎 ？如果你還想了解更多這方面的信息，記得收藏關(guān)注本站。
創(chuàng)新互聯(lián)【028-86922220】值得信賴的成都網(wǎng)站建設(shè)公司。多年持續(xù)為眾多企業(yè)提供成都網(wǎng)站建設(shè),成都品牌建站設(shè)計(jì),成都高端網(wǎng)站制作開(kāi)發(fā),SEO優(yōu)化排名推廣服務(wù),全網(wǎng)營(yíng)銷讓企業(yè)網(wǎng)站產(chǎn)生價(jià)值。
網(wǎng)站欄目：如何監(jiān)測(cè)數(shù)據(jù)庫(kù)增長(zhǎng)？(查看數(shù)據(jù)庫(kù)數(shù)據(jù)增長(zhǎng)情況)
網(wǎng)站鏈接：http://m.fisionsoft.com.cn/article/dpoijps.html
