MySQL如何控制用戶輸錯密碼嘗試次數？

目錄

• 生產環境MySQL死鎖如何監控及如何減小死鎖發生的機率
• MongoDB有哪些優秀特性及適合的場景是什麼
• GO語言對比其餘的編程語言有何優點？實際生產環境如何取捨？
• 一個大事務，有不少更新，如今被回滾了，可是又着急關機重啓，怎麼辦纔好？
• 如何下降UPDATE/DELETE時WHERE條件寫錯，或者壓根沒寫WHERE條件帶來的影響
• MySQL如何控制用戶輸錯密碼嘗試次數？

---

1、生產環境MySQL死鎖如何監控及如何減小死鎖發生的機率

首先，死鎖並非"鎖死"，死鎖是因爲兩個或兩個以上會話鎖等待產生迴路形成。

（一）死鎖監控及處理方法

對於死鎖的監控，各個版本都提供了innodb_print_all_deadlocks選項，打開該選項即會將死鎖的日誌輸出到MySQL的錯誤日誌當中,所以能夠經過監控錯誤日誌來達到監控死鎖的目的。而對於MariaDB就更加簡單了，MariaDB提供了Innodb_deadlocks的計數器，能夠經過監控該計數器的增加來監控是否存在發生死鎖。
假如線上出現死鎖而且頻率較高的話，務必要引發重視。因爲死鎖日誌僅記錄了最後引發死鎖的兩條SQL，所以並不能經過死鎖日誌當即定位
出死鎖的緣由，應當及時協同開發模擬出死鎖過程，分析死鎖產生緣由，修改程序邏輯。

（二）如何下降死鎖發生的機率

一、儘可能使用短小事務，避免大事務
二、加FOR UPDATE/LOCK IN SHARE MODE鎖時，最好下降事務隔離級別，例如用RC級別，下降死鎖發生機率，也能夠下降鎖定粒度
三、事務中涉及多個表，或者涉及多行記錄時，每一個事務的操做順序都要保持一致
四、經過索引優化SQL效率，下降死鎖機率，避免全表掃描致使鎖定全部數據
五、程序中應有事務失敗檢測及自動重複提交機制
六、高併發（秒殺）場景中，關閉innodb_deadlock_detect選項，下降死鎖檢測開銷，提升併發效率

2、MongoDB有哪些優秀特性及適合的場景是什麼

（一）優秀特性

一、實用性：面向類json富文檔數據模型，對開發人員自然的友好
二、可用性：基於raft協議的自動高可用，輕鬆提供99.999%的可用性
三、擴展性：對分片集羣的支持，爲業務提供了友好的水平擴展
四、高性能：嵌套模型設計支持，減小了離散寫，充分的物理內存利用率，避免了磁盤讀
五、強壓縮：WiredTiger引擎提供多種數據壓縮策略，2~7倍的壓縮比，大大節省了磁盤資源

（二）適合的場景

一、無多文檔事務及多表關聯查詢需求
二、業務快速迭代，需求頻繁變更行業
三、單集羣併發過大沒法支撐業務增加
四、數據量增加預期TB及以上存儲需求
五、指望要求99.999%數據庫高可用場景

3、GO語言對比其餘的編程語言有何優點？實際生產環境如何取捨？

一、天生支持高併發，強一致語言，開發效率高兼具線上運行穩定安全
二、垃圾回收，不用關心內存分配與回收
三、強大的GMP模型，異步處理，支持高併發，小白也能輕鬆寫出高併發代碼

在實際生產環境中建議從以下幾個方面考慮：

一、看業務場景，電商，大數據處理有現成的解決方案，不適合用。另外數學運算，cpu 密集型的也不用。
二、GO 擅長快速出業務原型，迭代開發效率高，初創公司強推
三、看公司開發的技術棧，若是差別較大，那麼選用 GO的話上手更快，編程風格也能統一塊兒來

4、一個大事務，有不少更新，如今被回滾了，可是又着急關機重啓，怎麼辦纔好？

一、首先，儘可能避免在MySQL中執行大事務，由於大事務將會帶來主從複製延遲等問題
二、大事務被kill，MySQL會自動進行回滾操做，經過show engine innodb status的TRANSACTIONS能夠看到ROLLING BACK的事務，而且在回滾操做的時候仍然會持有相應的行鎖
三、此時若是強行關閉MySQL，等到MySQL再次啓動後，仍然會進行回滾動做
四、所以，爲確保數據安全，建議仍是耐心等待回滾完成之後再進行關機重啓。關機重啓前，能夠調低innodb_max_dirty_pages_pct讓髒頁儘可能刷新完畢，而且關閉innodb_fast_shutdown
五、假如實在沒有辦法須要關機的狀況下，能夠kill -9先關閉MySQL，前提是須要設置雙一保證事務安全，不然可能丟更多事務數據。而後重啓實例後innodb會自行crash recovery回滾以前的事務

PS， kill -9是高危操做，可能致使MySQL沒法啓動等不可預知的問題，請謹慎使用

5、如何下降UPDATE/DELETE時WHERE條件寫錯，或者壓根沒寫WHERE條件帶來的影響

一、儘可能不要在線手工執行任何SQL命令，很容易出差錯。線上直接執行SQL命令最好有第二檢查人幫助確認
二、最好在測試環境執行SQL確認無誤後，再到生產環境執行，或者提早在本地文本環境編輯好確認後再執行
三、建議打開sql_safe_updates選項，禁止沒有WHERE條件或者不加LIMIT或者沒有使用索引條件的UPDATE/DELETE命令被執行。也能夠在用mysql客戶端鏈接到服務器端時增長--safe-updates選項，例如：mysql --safe-updates -h xx -u xx
四、線上手動執行DML操做時，先開啓事務模式，萬一誤操做能夠回滾。例如：mysql> begin; update xxx; rollback;
五、經過DB管理平臺執行DML操做，且在平臺上增長對此類危險SQL的判斷，直接拒絕危險SQL的執行
六、配置延遲從庫，發現誤刪除數據後，從延遲從庫快速恢復數據

6、MySQL如何控制用戶輸錯密碼嘗試次數？

（一）插件輔助

從官方MySQL5.7.17開始，提供了CONNECTION_CONTROL和CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS插件，該插件又提供了connection_control_failed_connections_threshold、connection_control_min_connection_delay、connection_control_max_connection_delay三個參數

一、connection_control_failed_connections_threshold
該參數的含義是控制登錄失敗多少次數後開啓延遲登錄

二、connectioncontrolminconnectiondelay
該參數分別表示超過失敗次數後每次從新鏈接最小的延遲時間，延遲計算公式爲(當前失敗總次數-失敗閾
值)connectioncontrolminconnection_delay，所以錯誤嘗試次數越多那麼延遲時間也是越大

三、connection_control_max_connection_delay
最大延遲時間，超過該值後客戶端可從新鏈接

四、安裝插件後，可經過監控Connection_control_delay_generated狀態值和INFORMATION_SCHEMA下的表CONNECTION_CONTROL_FAILED_LOGIN_ATTEMPTS來監控錯誤登陸嘗試次數

（二）錯誤日誌監控

經過定時掃描MySQL錯誤日誌來捕獲帳號密碼錯誤次數，達到某個閾值之後可在系統防火牆屏蔽對應的主機ip達到屏蔽帳號的目的(具體操做視狀況而定)
如：錯誤日誌會顯示2019-05-10T13:04:41.232259Z 5 [Note] Access denied for user 'xucl'@'127.0.0.1' (using password: YES)

（三）其餘說明

一、有些同窗會誤覺得max_connection_errors可以控制錯誤密碼的嘗試次數，其實該參數只能防止如telnet類的端口探測，即記錄協議握手錯誤的次數
二、最後，在生產環境必定要關注aborted_clients和aborted_connects的狀態，發生異常必須及時關注

---

公衆號：知數堂，更多MySQL乾貨知識，關注公衆號獲取。

原文連接：https://zhishutang.com/CID

推薦閱讀：https://zhishutang.com/xdI