MySQL許可權處理的一個小bug
- 2019 年 10 月 4 日
- 筆記
這是學習筆記的第 2103 篇文章
最近碰到了一個奇怪的許可權問題，問題的背景是業務同學回饋在下班後，有一個數據表出現了阻塞，導致後續的業務流程都產生了擁堵，在對這個問題進行分析發現，業務同學所謂的擁堵，阻塞是資料庫連接出了問題。當然我們進行了一些深入的溝通，對整個問題的情況有了一個更為清晰的了解。
6:30左右，業務同學發現程式端產生了阻塞，程式端正在處理的操作是一個create table的操作。
6:40左右，業務同學嘗試通過客戶端工具連接到資料庫來手工執行，但是發現連接超時，根據業務同學回饋，之前是能夠正常連接的。
6:50左右，業務同學開始呼叫DBA進行處理。
7:00左右，DBA就位後，什麼都沒做，就魔法般的解決了問題。
對於業務同學的印象，是資料庫不夠穩定，因為另外一套環境也出現了類似的問題，這是一個很糾結的情況，我們如同哆啦A夢般的存在，但是實際上什麼都沒有做就解決了問題。
當然在我的職業生涯中，對待問題我是不相信神奇的力量，事出有因，我希望找到那些看起來簡單的問題的答案。
從業務同學的回饋時間點開始，我嘗試找到一些相關的日誌來看看，從資料庫的處理來看，是不大可能阻塞DDL中的create操作的，無論伺服器壓力大小，這算是DDL裡面最正常的需求了，絕對不應該阻塞幾十分鐘。
幸運的是，我很快找到了相關的binlog日誌，簡單解析之後，看到了下面的內容。
從內容來看，情況和業務同學回饋的時間點是吻合的，業務邏輯會自動創建相關的時間表，而下一次create則是在20多分鐘之後，這裡的問題就來了，為什麼創建兩張表的過程中會有這些許可權處理的語句出現?
看這些許可權處理的語句還是比較規範的，而且從執行日誌來看不大像是人工執行的，因為整個許可權的處理涉及的語句條數還比較多，從執行上來看，像是工具生成的。
我查看了下相關時間範圍內的工單數據，發現在那個指定的時間段里，確實有同事在處理幾個相關的工單，帶著這個資訊和同事確認，才發現這兩件看起來不相關的事情還是有關聯的。
業務同學回饋，有兩套環境都出現了類似的問題，和工單數據比對發現，情況是完全相符的，在出現問題的時間段里產生了阻塞。
我們來仔細看一下這條語句：
GRANT USAGE ON *.* TO 'srv_datasync_rwh'@'192.168.18.%' IDENTIFIED WITH 'mysql_native_password' AS '*5EEBC522DE487B0D5C2506C65412F9C337F70C40'
這條語句是對於192.168.18端的客戶端開通相應的許可權，而這個grant語句其實是類似MySQL 5.7的create user語句，帶著這個問題繼續下鑽，發現原來這個資料庫中本身是存在用戶'srv_datasync_rwh'@'192.168.18.%' 的，在這裡，相當於工具重新生成了完整的授權語句，對已經存在的用戶進行了重新授權，這個操作的代價有點類似於許可權重置。
而這個問題在測試環境中模擬是直接復現不了的，整個問題和觸發的上下文環境也有相關性，同時對涉及到許可權處理的完整過程中產生了額外影響，有點類似於在購物網站中，一邊在購物下單，另一邊在同時做密碼重置，這是一種較為模糊的臨界狀態。
總體來說，這個許可權問題還是相對可控的，我們需要修復運維工具自動生成的語句的邏輯，對於5.7版本的使用create user，grant這種組合授權模式。
