SKIP-NAME-RESOLVE ——错误的使用时机造成用户权限
2019獨角獸企業重金招聘Python工程師標準>>>
以下內容是網上找的,問題解決的關鍵是將mysql配置文件中的“skip-name-resolve”注釋掉,重啟mysql,接著就好了!
新加的一臺服務器,連接內網中的一臺mysql服務器的時候,經常出現超時。
登陸到mysql,查看進程的信息
show processlist;
發現大量的進程的狀態為 login
原來默認的時候mysql啟動時是不使用 skip-name-resolve選項的,這樣的話,從其它主機的連接會比較慢,因為mysql會對這個ip做dns反向查詢,導致大量的連接處于 login狀態.....
解決這個問題有兩個辦法
一是加入 skip-name-resolve參數重啟mysql
二是在 /etc/hosts中加入一句 192.168.0.2 server2 其中 192.168.0.2是新加的服務器的內網ip,server2是新服務器的主機名
在mysql客戶端登陸mysql服務器的登錄速度太慢的解決方案一篇文章中,我介紹了如何通過在my.ini文件(linux下是my.cnf文件)中添加"SKIP-NAME-RESOLVE"的參數設置,使得客戶端在登錄服務器的時候不通過主機解析這一關,直接登陸的方法,以此來提高登錄速度。
這里要介紹一下這種方法的負面作用,以及不合理的時機使用這種方法會引發的不可發現的錯誤。
首先,回顧一下在my.ini文件中添加"SKIP-NAME-RESOLVE"參數來提高訪問速度的原理:
在沒有設置該參數的時候,客戶端在登陸請求發出后,服務器要解析請求者是誰,經過解析,發現登錄者是從另外的電腦登錄的,也就是說不是服務器本機,那么,服務器會到mysql.user表中去查找是否有這個用戶,假設服務器IP是192.168.0.1,而客戶機的IP是192.168.0.2;那么查詢的順序是先找'root'@'192.168.0.2'這個user是否存在,若存在,則匹配這個用戶登陸,并加載權限列表。若沒有該用戶,則查找'root'@'%'這個用戶是否存在,若存在,則加載權限列表。否則,登錄失敗。
在設置了SKIP-NAME-RESOLVE參數后,客戶端的登錄請求的解析式同上面一樣的,但是在服務器本機的解析過程卻發生了改變:服務器會把在本機登錄的用戶自動解析為'root'@'127.0.0.1';而不是'root'@'localhost';這樣一來就壞了,因為我們在服務器上登錄是為了進行一些維護操作,但是顯然,'root'@'127.0.0.1'這個用戶是被默認為'root'@'%'這個用戶的,這個用戶還沒有足夠得權限去執行一些超級管理員'root'@'localhost'才能執行的大作。因為未分配權限。
所以結論是:加入你在服務器本機上登錄mysql服務器的話,要么先取消SKIP-NAME-RESOLVE的參數設置,重新啟動服務器再登陸,設置完成后,再設置上該參數;要么就給'root'@'127.0.0.1'分配超級管理員權限,但這么做顯然是不明智的,因為任何人在任何機器上都可以用這個用戶執行管理員操作,前提是知道了密碼。
我有一次在mysql服務器上執行數據庫創建腳本,并同時創建表、觸發器、存儲過程等。結果,總是失敗,經過了一上午的折騰,最后發現時這個參數造成我以'root'@'127.0.0.1'這個用戶登陸了服務器,這個用戶沒有創建觸發器的權限。后來,取消了SKIP-NAME-RESOLVE參數后,執行成功,再把該參數設置回去。重啟。OK。
所以,在設置這個參數的時候一定要注意時機:先用超級管理員將所有的用戶創建好,再將權限分配好之后,才設置這個參數生效。
轉載于:https://my.oschina.net/CraneHe/blog/197903
總結
以上是生活随笔為你收集整理的SKIP-NAME-RESOLVE ——错误的使用时机造成用户权限的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: C#重写和覆盖
- 下一篇: 《运营之光》《策略产品经理》《推荐系统实