sql審核-避免離線sql導致的db集群故障

關鍵詞： sql審核、sql審批、sql檢查、sql檢測、sql執行

離線sql可能會導致的問題

首先，什么是離線sql呢？就是說手動觸發執行的這種sql；相對的還有在線sql，位于我們的程序代碼中，由程序觸發執行的sql是在線sql。舉個例子，我們想要建庫、建表、改表的時候，通常會編寫sql語句，選一個合適的時間執行；這就是離線SQL。當然，操作數據的離線sql也是有的，比方說線上程序bug，我們想要手動修復個別數據，這時候也會提交離線的修改數據的SQL。

那么，離線的sql可能會導致哪些問題呢？這個說起來還挺多的，我們來列舉一下。建表或者改表的時候，可能會存在不規范的列，比如我們可能會不希望字段存在空值；可能會不小心使用不同的字符集；可能會不小心創建了重復的索引，給變更數據帶來不必要的負擔。而操作數據的時候，如果數據量特別大，一個不走索引的查詢或者變更語句就可能給db帶來災難；或者偶爾由于手速過快，提交了不帶條件限制的變更語句；另外，手動操作難免偶爾出錯，出錯了再去糾正數據也會十分麻煩。

如何避免問題

如何避免這些問題呢？最簡單的方式是我們每次執行sql都提交給dba，由dba同學手動檢查后執行。如果公司規模很小，這樣的話還能湊合（如果公司有dba同學的話），但人工審核也難免有注意不到的地方；而公司規模比較大的話，就比較費dba同學了【手動狗頭】。

那我們可以在這個基礎上再加一層：由研發leader審核完后，再由dba同學審核并執行。這樣可以減輕dba同學的工作量，但是還是沒有辦法避免人工檢查的遺漏。而且也沒有辦法方便的進行數據備份。

那么有沒有更好的方式呢？當然是有的，把檢查sql的標準梳理清楚形成一條一條的規則，然后固化到程序里，由程序來應用規則完成首輪檢查，并在執行的時候，進行數據備份，需要時還可以進行數據回滾。

現成可使用的工具-Owl

Owl就是這樣一個開源工具，它提供sql提交流程審批、按規則檢測sql、執行sql、備份、回滾等功能，可以用以管理起來所有的離線sql執行場景。它讓我們的db數據更規范、db集群更安全。下圖是它的一個流程結構示意圖。

首先它提供一個審批流程的地方，研發同學想要對自己訪問不到（網絡隔離）的線上環境執行sql時，可以在Owl上提交sql執行的請求工單，分別經過規則審核、leader審核、dba審核后，由dba在Owl上直接執行。

規則審批即是通過一些規則限制可執行的sql。這些規則的實現還是挺有意思的，感興趣的同學可以去代碼中看，文末會有地址。規則舉例：1，表必須使用utf8字符集；2，列和表都必須要有注釋；3，變更數據影響行數不能超過100；4，變更數據的sql必須完全匹配索引。上面這些都是具體的規則，規則可以打開或者關閉，打開狀態的規則會拒絕不滿足此條規則的sql。下圖是具體支持的部分規則截圖，目前已實現37條規則。

dba審核通過后，可以選擇定時執行或者馬上執行，如果是操作數據的sql，則執行的時候會進行數據備份。之后，如果有需要可以進行數據回滾，回滾的時候會展示變更了哪些列以及原來的數據內容。下圖是回滾時的截圖,所修改行的數據會展示為紅色。

當然，為了可以使用上述的一些功能還需要一些基礎的功能模塊，比如用戶、管理員管理，集群管理、登陸認證等。由于一些規則需要獲取具體的表數據信息來實現驗證，所以需要db的賬號和密碼。密碼是加密存儲在數據庫的，必須要有配置文件中的key和程序中固定的key才能解密，所以安全性是有保障的。

最后還需要說明的是：大批量的數據更新不適合通過owl去做，除非我們不需要做數據備份。因為owl的數據備份方式是特殊編碼后轉儲到一張db表里，數據量過大會給內存帶來很大的壓力，也不適合放到表里了。

未來規劃

首先是分庫分表工具（gh-ost）的支持，有的公司使用了分庫分表的模式，Owl如果可以配置化的支持這個工具，用起來會更方便一些。

其次是支持數據查詢功能，并使用部分規則加以限制，這是一個很常見的需求，沒什么好說的。

另外還想改造一下用戶相關的邏輯，讓沒有使用ldap做用戶管理的公司也能方便的用起來。讓使用更簡單是一個長期目標。

以上的規劃會在半年內逐步完成。

長遠來看還可以加入redis、es等其他存儲的讀寫功能，但是這個就比較久遠了。

求個star

最后，求一個star呀，每一個star都是對開源項目研發者的巨大鼓勵！

項目地址：https://github.com/ibanyu/owl