心得分享：趕集網三年DBA總結

2013年初入職趕集，當時處在流量訊猛增長的階段，3年DBA生涯收穫坡多，其實坑更多(淚... 後來在做開發時，慢慢體會到”維運“ 和“開發」 確實存在溝通問題：知識不對稱。如何解決呢？先總結下這三年吧

DBA職責

市面上招聘JD 一大堆，隨變找幾個，馬上能找出共性

市面上招聘JD 一大堆，隨變找幾個，馬上能找出共性

資料庫系統的規劃、設計、管理、遷移

資料庫的日常維護、備份、最佳化與復原

Master-Slave架構搭建、維護

業務系統上線支持，資料庫設計評審，提供架構方案

資料庫不限於MySQL, Oracle, 如果分的不細，還會有Redis, MongoDB 等一系列NoSQL。安全，例如備份及恢復，14年趕集審計，行動端的活躍用戶數就是從備份中恢復來的，可見備份的有效性是重中之重。個人生活被打斷就罷工，有一次剛看電影就被叫回去處理DB報警，罵娘的心都有了。

悲慘案例

先舉一些悲慘案例，讓看官們高興一下~ 由於一下~ 由於公司早就不在了，這裡沒有顧忌。恢復。到位，代碼review 肯定有缺失

2. 大賣家問題

房產在14年開通免費端口，短短幾個月時間房產商業表爆漲到100G，個別中介帳號發貼超過10W，導致數據庫異常抖動，威哥暫時清理過多發貼記錄解決。打跨主庫

主站主庫有一次被子查詢打跨，事後排查，由於RD 大量子查詢導致。不過沒有引起事故而已

反思：趕集DB 典型1 主N 從，沒有proxy 保護的懷況下，經常出現此類問題，只靠規範制度基本解決不了

4. 報表olap 庫問題

RP 庫我和文武背鍋，年底的績效墊底。阻塞，聽說公司因為報表連續問題賠商家300W。

反思：這事故得站在高處去看，免費連接埠開放太突然，專案技術負責人考濾不全。報表系統沒有經過設計，完全由一個新人RD去搞，也就大學畢設水平，回頭再看，hadoop spark 完全搞定。最後 DBA 沒有及時對大表進行跟踪，沒有提前發現。

5. 50G的Redis

房地產業務 Redis 眼看從 20G 爆漲到 50G，我離開後也一直沒優化掉。後來某次故障，資料清空了？

我的工作

大部份時間和開發溝通感情聊人生，後來automan 上線很少有人找我了~ 每個階段都有成長，都有感謝的人和事，趕集讓我有平台去做有興趣的事，很開心。

剛到趕集時，SQL 上線還走的jira，半自動化由維運開發同學做的，經常在技術大群裡被艾特，很簡單的建表或是DML 都要由DBA 人工介入，很煩索。另外很多建表語句不規範，打回讓RD 修改，他們對此很有意見，認為無所謂的修改，這就在RD和DBA之間產生了溝通成本，詩展在的時候還會定期做數據庫開發培訓，然後就沒有然後了。

14年中著手 automan 平台開發，從前台頁面到後端訊息佇列，到 sql parser 解析，從無到有，在劉軍先河同學的幫助下最終上線完成。由平台去審核開發的 SQL，經過 sim 模擬環境，再到線上自動執行備份，比人工高效的多。

這個系統原理和市面上其它工具差不多，扔有很大改進的地方。後來在資料庫大會分享了一次，誠惶誠恐沒有被噴。

DBA 心得

夯實基礎：DB 的基礎自然是穩定，穩定，再穩定。實例數一多，基本上每天都會遇到各種故障。主掛了就用 MHA 切換(最新的有gtid)，slave 掛掉就由 lvs 自動摘掉讀流量。還有一個就是備份，全量增量，定期備份有效性檢測，每一塊都需要人力的投入。

硬體優先：DB擴充有 scale up 和 scale out 兩種，一般優先堆硬體。 buffer 不夠加內存，128G 不夠就 192G，磁碟陣列卡效能不行就上 SSD，再不行就上 flash 闆卡。總之優先考濾硬件，爭取架構優化的時間。

未雨綢繆：慢SQL 優化，定期出報表讓RD 調優，一般出問題都是索引沒加，99%的大SQL都是這樣，少部份因為表設計不合理(沒有自增主鍵，或是頻煩修改)。大表監控，該瘦身的瘦身，字段該拆的拆，橫豎兩刀，過期數據定期歸檔，基本上就這些事。

結合業務：有些優化 DBA 累的半死，不如 RD 修改一行程式碼。 DBA 也要多和業務接觸，了解業務實現，不求給業務貢獻多少，不背鍋就好... 開玩笑。了解業務，就能站在更高的角度思考，很有意義。

學會拒絕：這個拒絕不是罷工不干活，而是要分清哪些需求的合理性與緊急性，不合理也不緊急的直接幹掉，緊急但不合理的可以臨時通過，快速解決問題，事後再的確掉也可以。例如 olap 跑在了線上函式庫，count(*) 計數 SQL 完全可以非同步走計數器，Redis 是好東西。

學會溝通：工作也有些年頭了，這一點仍然在學習，也犯過不少錯。溝通好權責，定下時間表。

踏實學習：回頭看當年DBA做的不夠好，有些原因在於沒有開發能力，很多想法止步於此。維運人員一定要有開發功力，並且要比業務 RD 更精，才能做好運維。

運維RD的矛與盾

KPI 不同，關注點自然也不同，一線的同學經驗也都有欠缺，特別是剛工作1~2年的，造成了資訊與知識的不對稱。解決這個問題也不難：

新人要有導師帶，對新人放手不管最不負責。這方面感覺 nice 做的不錯。該誇還是要誇的。

支援團隊要有足夠的 wiki 業務文件說明。

自動化用技術來約束，而不是人工。同比業務介面強約束，現在服務化都用 thrift 了。

對趕集的記憶已經越來越模糊了，唯有...

總結寫了一部分後，原同事都說遺漏了一些，那就一齊追加到後面，版權不歸我:)

20170214 以下內容來自原同事： 李瑞

回憶下趕集的dba生活

總結下就是各種故障多，隨時候命，需要處理，這些直到automan出來，強制rd通過平台上線後，稍微好一點。

因為raid0的問題，至少遇到4-5次master硬碟的問題，需要緊急處理。

tg 遇到1次，ms 切過次，似乎也是磁碟的問題。

其他slave 備份機，硬碟故障更是多，最多一週需要處理4起磁碟的問題。而趕集的mysqldb 一般都大至少100G，資料報表庫的磁碟有2.3T，沒辦法透過備份的方式重架從函式庫，我用了2-3週才搞定

im 的swap 問題

Imm的swap問題，肯定是sql的問題，主要的查詢sql 是透過order by，count 來取得數據，這個問題，從我進去趕集到出來一直是無法解決。只能是手動lvs切割流量，重啟slave，再lvs回切流量 解決swap的問題。 1週幾乎需要1-2次。告訴過im同事幾次im sql問題，希望對count查詢可以自己做個計數器，但最後也沒下文了。關閉swap 又怕伺服器會經常oom。 最後還是趙慎舉同學來了後，開啟了預熱innodb_buffer_pool的參數後，可以直接重啟slave，而不怕因為預熱的問題load突增。其他趙慎舉同學改了numa限制內存，不過im的swap最後也沒解決。

備份

備份的問題，1是磁碟空間的問題，1個還是raid0的問題。 。

最後你們走後，有1個月我獨立支撐，直到畢常奇來了，6台，還是7台備份機，硬碟壞的是此起彼伏。 Log庫，emp，還有王緒峰組,我忘了業務線的名稱了，暴漲到800G的數據，備份機壞了，再加上空間不足。我索性停了備份，最後只保證了ms，hp,tg,tc一些大庫的備份，這個58同事接手後估計會被他們鄙視壞了。

這個其實後來華為32T的備份機來了以後，備份機制應該變通的，怪我

還有異機備份，每2個月4個2T盤就會保存滿了，更換，挪盤，手動做raid掛盤，手動excle做記錄。最後還真有次要用到這些盤來查找資料。

磁碟問題

Hp 兩個大表，需要定期清理資料。 Ms 磁碟每天10G的成長速度，而且ms需要用pcie卡，最後終於可以從800 擴到1200。可以消停幾個月。 Ms 有幾台機器，最後就差10G 左右就要滿了。各種刪日誌，各種挪數據，東牆補西牆，（搞的我知道400G 的ssd 做xfs 要比ext4 能省20G 的空間，剛好夠給ms用），而且磁碟的增長，伴隨著備份機，磁碟空間不足，sim機（提供唯讀服務給開發的我忘記叫什麼了）空間不足。還有report庫，想申請磁碟，伺服器，機櫃沒有位置了，就這樣挺著單庫跑了很久。

還有就是王緒峰組和tc 的透過框架產生的sql

產生多餘的子表，varchar 類型的欄位條件不加單引，再加上上線建表不加索引，定期需要檢查sql，進行最佳化。

痛苦的hp，主庫拆分。

歷時1年多，沒有分拆完整 。最後聽畢常奇說，瓜子二手車從這些柯瑞分拆。自上而下，強行拆分。 1-2天拆分了。

php的短連接，連接數滿

這個最後的最後，你們走了後，偶爾在分析hp全日誌，發現hp每1-2次連接，伴隨著一次空連接。 Connect 什麼都不做 quit。這個問題不知道什麼有的，改了後，hp的連線數問題好了。

總結，在趕集，因為數據的暴漲，只是一味的應對，沒有快刀斬亂麻，進行分拆。還有就是有個dba的平台真是必要，管理監控，提交審核sql，這個直到後來我才能夠模仿著automan勉強寫了個。

文章由php中文網網友澤潤供稿，轉載請註明，本文網址：http://www.php.cn/toutiao-352102.html