趕集網三年 DBA 總結（轉）

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

---

DBA職責

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

• 數據庫系統的規劃、設計、管理、遷移
• 數據庫的平常維護、備份、優化及恢復
• Master-Slave架構搭建、維護
• 業務系統上線支持，數據庫設計評審，提供架構方案

數據庫不侷限於 MySQL, Oracle, 若是分的不細，還會有 Redis, MongoDB 等一系列 NoSQL。工做內容都同樣，首先是高可用穩定性，不能今天抖動明天宕機，涉及工做不少。第二個是數據安全，好比備份及恢復，14年趕集審計，移動端的活躍用戶數就是從備份中恢復來的，可見備份的有效性是重中之重。最後一個固然是爲業務服務，對接業務需求，不能因我的生活被打斷就罷工，有一次剛看電影就被叫回去處理DB報警，罵孃的心都有了。

悲慘案例

先舉一些悲慘案例，讓看官們高興一下~ 因爲公司早就不在了，這裏沒有顧忌。

1. delete 刪全表

二手車同窗的鍋，SQL 拼錯不帶 where 條件，編寫線下腳本時出錯... 最後DBA根據 row binlog 恢復。至少2次:(

反思：rd 新手一茬又一茬，規範講再多也沒用。最完全的解決方式只有一個，接入 proxy, 限制一切非法 sql。另外 rd 上線驗證也不到位，代碼 review 確定有缺失

2. 大賣家問題

房產在14年開通免費端口，短短几個月時間房產商業表爆漲到 100G，個別中介賬號發貼超過10W，致使數據庫異常抖動，威哥臨時清理過多發貼記錄解決。最後耗時三個月對這張表進行瘦身，拆分 text 字段。

反思：DBA 對大表監控不足

3. 大量子查詢打跨主庫

主站主庫有一次被子查詢打跨，過後排查，因爲 RD 大量子查詢致使。此類問題不是個案，有不少 RD 把本本該讀 slave 的請求寫到 master 上，只不過沒有引發事故而已

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

4. 報表 olap 庫問題

RP 庫我和文武背鍋，年末的績效墊底。文武接手前的 RD 一我的開發中介商家報表系統，全部計算都是基於 DB，當免費端口開放後數據量爆漲，MyISAM 讀寫鎖致使大量請求阻塞，據說公司由於報表連續問題賠商家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經過平臺上線後，稍微好點。

1. 由於raid0的問題，至少遇到4-5次master硬盤的問題，須要緊急處理。
   tg 遇到1次，ms 切過次，貌似也是磁盤的問題。
   其餘slave 備份機，硬盤出故障更是多，最多一週須要處理4起磁盤的問題。而趕集的mysqldb 廣泛都大至少100G，數據報表庫的磁盤有2.3T，無法經過備份的方式重架從庫，我用了2-3周才搞定

2. im 的swap 問題
   Im 的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是最後也沒解決。

3. 備份
   備份的問題，1是磁盤空間的問題，1個仍是raid0的問題。。
   最後大家走後，有1個月我獨立支撐，直到畢常奇來了，6臺，仍是7臺備份機，硬盤壞的是此起彼伏。 Log庫，emp，還有王緒峯組,我忘記了業務線的名稱了，暴漲到800G的數據，備份機壞了，再加上空間不足。我索性停了備份，最後只保證了ms，hp,tg,tc一些大庫的備份，這個58同事接手後估計會被他們鄙視壞了。
   這個其實後來華爲32T的備份機來了之後，備份機制應該變通的，怪我
   還有異機備份，每2個月 4個2T盤就會保存滿了，更換，挪盤，手動作raid掛盤，手動excle作記錄。最後還真有次要用到這些盤查找數據。

4. 磁盤問題
   Hp 倆個大表，須要按期清理數據。Ms 磁盤天天10G的增加速度，並且ms須要用pcie卡，最後終於能夠從800 擴到1200。能夠消停幾個月。Ms 有幾個臺機器，最後就差10G 左右就要滿了。各類刪日誌，各類挪數據，東牆補西牆，（搞的我知道400G 的ssd 作xfs 要比ext4 能省20G 的空間，剛恰好夠給ms用），並且磁盤的增加，伴隨着備份機，磁盤空間不足，sim機（提供只讀服務給開發的我忘記叫什麼了）空間不足。還有report庫，想申請磁盤，服務器，機櫃沒有位置了，就那樣挺着單庫跑了好久。

5. 還有就是王緒峯組 和tc 的 經過框架生成的sql
   生成多餘的子表，varchar 類型的字段條件不加單引，再加上上線建表不加索引，按期須要檢查sql，進行優化。

6. 痛苦的hp，主庫拆分。
   歷時1年多，沒有分拆完整 。最後聽畢常奇說，瓜子二手車從這些庫裏拆分。自上而下，強行拆分。1-2天拆分了。

7. php的短鏈接，鏈接數滿
   這個最後的最後，大家走了後，偶爾在分析hp全日誌，發現hp每1-2次鏈接，伴隨着一次空鏈接。Connect 什麼都不作 quit。這個問題不知道什麼有的，改了後，hp的鏈接數問題好了。

---

總結，在趕集，由於數據的暴漲，只是一味的應對，沒有快刀斬亂麻，進行分拆。還有就是有個dba的平臺真是很必要，管理監控，提交審覈sql，這個直到後來在完美一天的時候我纔可以模仿着automan勉強寫了個。

做者：董澤潤 連接：https://www.jianshu.com/p/58962c334a35 來源：簡書 簡書著做權歸做者全部，任何形式的轉載都請聯繫做者得到受權並註明出處。