今天就跟大家聊聊有關從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文件的恢復是怎樣的有進一步的了解嗎?如果還想了解更多知識或者相關內容,請關注創新互聯行業資訊頻道,感謝大家的支持。
當前名稱:從AnemometerBUG到FRM文件的恢復是怎樣的
鏈接URL:http://m.newbst.com/article28/gdiccp.html
成都網站建設公司_創新互聯,為您提供網站收錄、網站設計公司、響應式網站、做網站、微信公眾號、自適應網站
聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創新互聯