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通過平臺上線後，稍微好點。
- 因為raid0的問題，至少遇到4-5次master硬碟的問題，需要緊急處理。
tg 遇到1次，ms 切過次，貌似也是磁碟的問題。
其他slave 備份機，硬碟出故障更是多，最多一週需要處理4起磁碟的問題。而趕集的mysqldb 普遍都大至少100G，資料包表庫的磁碟有2.3T，沒法通過備份的方式重架從庫，我用了2-3周才搞定 - 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是最後也沒解決。 - 備份
備份的問題，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勉強寫了個。