從Anemometer BUG 到FRM文件的恢復是怎樣的

今天就跟大家聊聊有關從Anemometer BUG 到FRM文件的恢復是怎樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

最近深深體會到，目前的發展速度，數據庫方面各種東西，原理層出不窮，一個禮拜不去看那些公眾號去“滋養”，一下腦子，就發現新的概念不知道了。

題目是Anemometer， 估計大部分不是MYSQLER的不大清楚這是個什么東西，其實這是幾年前通過WEB界面查詢MYSQL 慢查詢的一個方法，安裝上，通過一些腳本，就可以讓每個MYSQL的服務器的慢查詢顯示出來。

本來應該是駕輕就熟的事情，裝上去，然后每臺機器傳送慢查詢的語句過來，在進行查看，沒有那么的復雜，可就是簡單的問題，發現安裝上，根本不顯示東西，在注意一下github 上安裝的方法和配置文件的部署方式上已經變化了，按照變化的方式搞了半天，還是無法顯示。

后來請來單位的PHP 牛人，給看了一下PHP程序，找到其中的BUG，發現是$system_timezone 無法獲得正確的時間區域，造成的，指定了一下時間區域，github上的 Anemometer開始工作了。

當然后續頭疼的事情也有，PT工具輸入后的數據和數據庫中的結構有不一致的情況。所以有些時候某些開源軟件的使用只是一段時間，而后期如果公司有強需求，需要考慮自己去開發一套這樣的東西。

按下鍋蓋，起了瓢，最近MYSQL 的測試服務器，因為整改，原來的設置, 所有的文件都沒有per file ，而是都在一個ibd 文件，整改后就出了問題，數據讀不出來了，測試的數據倒是不重要，但是表結構對于測試時重要的，開發人員希望能恢復MYSQL 的表結構，根據原來的經驗，直接的選擇就是 mysql-utilties 工具集合里面的 frm文件修復，本來想的很簡單，現實很骨感，服務器上的PYTHON 版本 3.6， 由于對于python + LINUX 的更換版本的操作，本人表示，很白癡。搞到最后，連YUM 都不OK 了，（因為YUM 使用PYTHON），所以最后的結果是從新找了太干凈的機器，按照老的方法把 mysql-utitiles 裝上，然后恢復FRM 文件，本來還在擔心這個工具集已經走到生命的終點，（其實還是蠻好用）。后來一想，MYSQL 8.0 就沒有 FRM 文件了，這個功能就不需要在擔心了。

另外最近工作中發現一個項目，對數據庫的選型越來越有需求，比如一個需求里面如果客戶，強烈希望有模糊查詢，并且對RDS數據庫的需求，那如果繼續選擇 ORACLE  SQL SERVER , MYSQL 將對程序員是一件痛苦的事情，明擺著如此查詢早晚出性能問題的事情，如果不對各種數據有了解，那閉眼去選擇大概率是要吃虧的，后期程序上要搞模糊查詢的成本會比較高，而如果知道 POSTGRESQL 的能力，則毫無疑問的直接選擇，降低開發和運維的成本。又例如，數據選擇了MYSQL ，但數據的經常有瞬間的 IN OUT  高峰，那就的分析高峰時刻是否有緩解的方法，例如把MYSQL 進行分庫，或者使用REDIS + MQ 的方式前期將數據HOLD在前端，后續讓數據庫慢慢消費，這些都是有場景的，所以脫離業務去單純的談架構， that's a day dream.

所以我一直認為，不理解業務，就去使用一個種database是很草率的，并且數據庫發展到今天，傳統關系型， NO SQL , NEW SQL  ，內存數據庫，時序數據庫， 選擇的余地是越來越大，需要了解的東西也越來越多。

看完上述內容，你們對從Anemometer BUG 到FRM文件的恢復是怎樣的有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。