MySQL控制用戶輸錯(cuò)密碼嘗試次數(shù)

一、生產(chǎn)環(huán)境MySQL死鎖如何監(jiān)控及如何減少死鎖發(fā)生的概率

首先，死鎖并不是"鎖死"，死鎖是由于兩個(gè)或兩個(gè)以上會(huì)話鎖等待產(chǎn)生回路造成。

（一）死鎖監(jiān)控及處理方法

對(duì)于死鎖的監(jiān)控，各個(gè)版本都提供了innodb_print_all_deadlocks選項(xiàng)，打開(kāi)該選項(xiàng)即會(huì)將死鎖的日志輸出到MySQL的錯(cuò)誤日志當(dāng)中,因此可以通過(guò)監(jiān)控錯(cuò)誤日志來(lái)達(dá)到監(jiān)控死鎖的目的。而對(duì)于MariaDB就更加簡(jiǎn)單了，MariaDB提供了Innodb_deadlocks的計(jì)數(shù)器，可以通過(guò)監(jiān)控該計(jì)數(shù)器的增長(zhǎng)來(lái)監(jiān)控是否存在發(fā)生死鎖。
假如線上出現(xiàn)死鎖并且頻率較高的話，務(wù)必要引起重視。由于死鎖日志僅記錄了最后引起死鎖的兩條SQL，因此并不能通過(guò)死鎖日志立即定位
出死鎖的原因，應(yīng)當(dāng)及時(shí)協(xié)同開(kāi)發(fā)模擬出死鎖過(guò)程，分析死鎖產(chǎn)生原因，修改程序邏輯。

（二）如何降低死鎖發(fā)生的概率

1、盡量使用短小事務(wù)，避免大事務(wù)
2、加FOR UPDATE/LOCK IN SHARE MODE鎖時(shí)，最好降低事務(wù)隔離級(jí)別，例如用RC級(jí)別，降低死鎖發(fā)生概率，也可以降低鎖定粒度
3、事務(wù)中涉及多個(gè)表，或者涉及多行記錄時(shí)，每個(gè)事務(wù)的操作順序都要保持一致
4、通過(guò)索引優(yōu)化SQL效率，降低死鎖概率，避免全表掃描導(dǎo)致鎖定所有數(shù)據(jù)
5、程序中應(yīng)有事務(wù)失敗檢測(cè)及自動(dòng)重復(fù)提交機(jī)制
6、高并發(fā)（秒殺）場(chǎng)景中，關(guān)閉innodb_deadlock_detect選項(xiàng)，降低死鎖檢測(cè)開(kāi)銷，提高并發(fā)效率

二、MongoDB有哪些優(yōu)秀特性及適合的場(chǎng)景是什么

（一）優(yōu)秀特性

1、實(shí)用性：面向類json富文檔數(shù)據(jù)模型，對(duì)開(kāi)發(fā)人員天然的友好
2、可用性：基于raft協(xié)議的自動(dòng)高可用，輕松提供99.999%的可用性
3、擴(kuò)展性：對(duì)分片集群的支持，為業(yè)務(wù)提供了友好的水平擴(kuò)展
4、高性能：嵌套模型設(shè)計(jì)支持，減少了離散寫，充分的物理內(nèi)存利用率，避免了磁盤讀
5、強(qiáng)壓縮：WiredTiger引擎提供多種數(shù)據(jù)壓縮策略，2~7倍的壓縮比，大大節(jié)省了磁盤資源

（二）適合的場(chǎng)景

1、無(wú)多文檔事務(wù)及多表關(guān)聯(lián)查詢需求
2、業(yè)務(wù)快速迭代，需求頻繁變動(dòng)行業(yè)
3、單集群并發(fā)過(guò)大無(wú)法支撐業(yè)務(wù)增長(zhǎng)
4、數(shù)據(jù)量增長(zhǎng)預(yù)期TB及以上存儲(chǔ)需求
5、期望要求99.999%數(shù)據(jù)庫(kù)高可用場(chǎng)景

三、GO語(yǔ)言對(duì)比其他的編程語(yǔ)言有何優(yōu)勢(shì)？實(shí)際生產(chǎn)環(huán)境如何取舍？

1、天生支持高并發(fā)，強(qiáng)一致語(yǔ)言，開(kāi)發(fā)效率高兼具線上運(yùn)行穩(wěn)定安全
2、垃圾回收，不用關(guān)心內(nèi)存分配與回收
3、強(qiáng)大的GMP模型，異步處理，支持高并發(fā)，小白也能輕松寫出高并發(fā)代碼

在實(shí)際生產(chǎn)環(huán)境中建議從如下幾個(gè)方面考慮：

1、看業(yè)務(wù)場(chǎng)景，電商，大數(shù)據(jù)處理有現(xiàn)成的解決方案，不適合用。另外數(shù)學(xué)運(yùn)算，cpu 密集型的也不用。
2、GO 擅長(zhǎng)快速出業(yè)務(wù)原型，迭代開(kāi)發(fā)效率高，初創(chuàng)公司強(qiáng)推
3、看公司開(kāi)發(fā)的技術(shù)棧，如果差異較大，那么選用 GO的話上手更快，編程風(fēng)格也能統(tǒng)一起來(lái)

四、一個(gè)大事務(wù)，有很多更新，現(xiàn)在被回滾了，但是又著急關(guān)機(jī)重啟，怎么辦才好？

1、首先，盡量避免在MySQL中執(zhí)行大事務(wù)，因?yàn)榇笫聞?wù)將會(huì)帶來(lái)主從復(fù)制延遲等問(wèn)題
2、大事務(wù)被kill，MySQL會(huì)自動(dòng)進(jìn)行回滾操作，通過(guò)show engine innodb status的TRANSACTIONS可以看到ROLLING BACK的事務(wù)，并且在回滾操作的時(shí)候仍然會(huì)持有相應(yīng)的行鎖
3、此時(shí)如果強(qiáng)行關(guān)閉MySQL，等到MySQL再次啟動(dòng)后，仍然會(huì)進(jìn)行回滾動(dòng)作
4、因此，為確保數(shù)據(jù)安全，建議還是耐心等待回滾完成以后再進(jìn)行關(guān)機(jī)重啟。關(guān)機(jī)重啟前，可以調(diào)低innodb_max_dirty_pages_pct讓臟頁(yè)盡量刷新完畢，并且關(guān)閉innodb_fast_shutdown
5、假如實(shí)在沒(méi)有辦法需要關(guān)機(jī)的情況下，可以kill -9先關(guān)閉MySQL，前提是需要設(shè)置雙一保證事務(wù)安全，否則可能丟更多事務(wù)數(shù)據(jù)。然后重啟實(shí)例后innodb會(huì)自行crash recovery回滾之前的事務(wù)

PS， kill -9是高危操作，可能導(dǎo)致MySQL無(wú)法啟動(dòng)等不可預(yù)知的問(wèn)題，請(qǐng)謹(jǐn)慎使用

五、如何降低UPDATE/DELETE時(shí)WHERE條件寫錯(cuò)，或者壓根沒(méi)寫WHERE條件帶來(lái)的影響

1、盡量不要在線手工執(zhí)行任何SQL命令，很容易出差錯(cuò)。線上直接執(zhí)行SQL命令最好有第二檢查人幫助確認(rèn)
2、最好在測(cè)試環(huán)境執(zhí)行SQL確認(rèn)無(wú)誤后，再到生產(chǎn)環(huán)境執(zhí)行，或者提前在本地文本環(huán)境編輯好確認(rèn)后再執(zhí)行
3、建議打開(kāi)sql_safe_updates選項(xiàng)，禁止沒(méi)有WHERE條件或者不加LIMIT或者沒(méi)有使用索引條件的UPDATE/DELETE命令被執(zhí)行。也可以在用mysql客戶端連接到服務(wù)器端時(shí)增加--safe-updates選項(xiàng)，例如：mysql --safe-updates -h xx -u xx
4、線上手動(dòng)執(zhí)行DML操作時(shí)，先開(kāi)啟事務(wù)模式，萬(wàn)一誤操作可以回滾。例如：mysql> begin; update xxx; rollback;
5、通過(guò)DB管理平臺(tái)執(zhí)行DML操作，且在平臺(tái)上增加對(duì)此類危險(xiǎn)SQL的判斷，直接拒絕危險(xiǎn)SQL的執(zhí)行
6、配置延遲從庫(kù)，發(fā)現(xiàn)誤刪除數(shù)據(jù)后，從延遲從庫(kù)快速恢復(fù)數(shù)據(jù)

六、MySQL如何控制用戶輸錯(cuò)密碼嘗試次數(shù)？

（一）插件輔助

從官方MySQL5.7.17開(kāi)始，提供了CONNECTION_CONTROL和CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS插件，該插件又提供了connection_control_failed_connections_threshold、connection_control_min_connection_delay、connection_control_max_connection_delay三個(gè)參數(shù)

1、connection_control_failed_connections_threshold

該參數(shù)的含義是控制登陸失敗多少次數(shù)后開(kāi)啟延遲登陸

2、connectioncontrolminconnectiondelay

該參數(shù)分別表示超過(guò)失敗次數(shù)后每次重新連接最小的延遲時(shí)間，延遲計(jì)算公式為(當(dāng)前失敗總次數(shù)-失敗閾
值)connectioncontrolminconnection_delay，因此錯(cuò)誤嘗試次數(shù)越多那么延遲時(shí)間也是越大

3、connection_control_max_connection_delay

最大延遲時(shí)間，超過(guò)該值后客戶端可重新連接

4、安裝插件后，可通過(guò)監(jiān)控Connection_control_delay_generated狀態(tài)值和INFORMATION_SCHEMA下的表

CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS來(lái)監(jiān)控錯(cuò)誤登錄嘗試次數(shù)

（二）錯(cuò)誤日志監(jiān)控

通過(guò)定時(shí)掃描MySQL錯(cuò)誤日志來(lái)捕獲賬號(hào)密碼錯(cuò)誤次數(shù)，達(dá)到某個(gè)閾值以后可在系統(tǒng)防火墻屏蔽對(duì)應(yīng)的主機(jī)ip達(dá)到屏蔽賬號(hào)的目的(具體操作視情況而定)
如：錯(cuò)誤日志會(huì)顯示2019-05-10T13:04:41.232259Z 5 [Note] Access denied for user 'xucl'@'127.0.0.1' (using password: YES)

（三）其他說(shuō)明

1、有些同學(xué)會(huì)誤以為max_connection_errors能夠控制錯(cuò)誤密碼的嘗試次數(shù)，其實(shí)該參數(shù)只能防止如telnet類的端口探測(cè)，即記錄協(xié)議握手錯(cuò)誤的次數(shù)

2、最后，在生產(chǎn)環(huán)境一定要關(guān)注aborted_clients和aborted_connects的狀態(tài)，發(fā)生異常必須及時(shí)關(guān)注

總結(jié)

以上所述是小編給大家介紹的MySQL控制用戶輸錯(cuò)密碼嘗試次數(shù)，希望對(duì)大家有所幫助，如果大家有任何疑問(wèn)請(qǐng)給我留言，小編會(huì)及時(shí)回復(fù)大家的。在此也非常感謝大家對(duì)腳本之家網(wǎng)站的支持！
如果你覺(jué)得本文對(duì)你有幫助，歡迎轉(zhuǎn)載，煩請(qǐng)注明出處，謝謝！