### **在互聯網時代可以說數據是公司最寶貴的資產，不出問題則罷，出問題就是滿地是血的狀況。** **小事故公司可能收入受損失，大事故可能直接導致公司破產** ``` 舉例:最近發生的數據庫事故 2020年XX公司因刪庫事件賠付1.5億元 2017年數據庫勒索黑客劫持2.6萬余臺服務 2015年XX宕機多個小時，導致股價下跌 。。。。 ``` >創業公司或者小中型公司中沒有專職的DBA，一般由技術leader或者運維人員來維護，中大型公司都會有一些專攻數據庫方面的牛人，專門的職位叫做DBA，對于公司的DBA他們的價值不可小覷，公司只要稍具規模，就必須做好數據庫的建設和維護工作，這也體現了DBA的重要性,也意味著DBA責任重大。 >一個公司的數據庫如果從來不出問題，那一定是因為流量小，或者沒有業務量，出問題也是學習的最好機會，如何在出現問題時候用最快的速度修復，這些都至關重要。 ### **1、關于數據庫最常見的問題** **1.1、數據庫選型** >對于大部分技術人員來說，公司使用哪一個數據庫，基本上無須你來決定，在加入一個公司的時候，大部分的技術選型早已經確定，除非是剛創業公司你是公司的技術負責人或者總監，可能會確定技術選型。尤其是數據庫，一旦選型再遷移的成本（學習、試錯）非常大。因此除非是技術有顛覆性的有事或者目前有難以攻克的技術問題，否則很少有公司會費時費力的做大的遷移。 >其實無論是技術選型還是技術轉型，有一個不能忽視的因素就是，技術人員能否駕馭這種技術，或者說是技術人員和技術領導熟悉這種技術。 >因為每個公司的業務不同，數據庫系統的應用場景也不一樣，每個公司針對不同的業務場景可能會使用多種數據庫，所以選型也不相同，但是可以肯定的是，沒有那個系統一定是最好的。 ``` 例如： 支付相關的業務需要強事務，強一致性支持的：開源的Mysql、PostgreSQL、新的分布式TiDB ,付費的oracle等 日志分析業務搜索相關的：Elasticsearch 緩存、秒殺相關：Redis、Cuchbase、Memcached 大數據分析：Hive、Cassandra、clickhouse 文檔型數據庫：Mongodb 圖數據庫：TigerGraph、Neo4j、Amazon Neptune、JanusGraph ``` >這也就是為什么很多公司選擇多個數據庫并存，并通過不同的技術和架構給予相關的業務場景最優的支持了，一旦選型失誤，就會有頻繁的問題出現，直接影響到用戶體驗。 >所有的技術選型和設計，都有它的應用場景，這也就是為什么很多公司選擇多個數據庫并存，并通過不同的技術和架構給予相關的業務場景最優的支持了，一旦選型失誤，就會有頻繁的問題出現，直接影響到用戶體驗。 **1.2、數據庫相關架構** 一說到架構大家一般會想到： >單實例：很容易理解，單庫概念. 垂直分組：單實例添加副本，如Mysql主從同步，讀寫分離，Mongodb的副本集、讀寫分離. 水平分片：比如寫一本書，非常厚上萬頁，為了方便閱，讀作者分成冊（10小本）如Tidb分布式關系型數據，redis的cluster，Mongodb的分片等. >架構還包括數據庫上層的緩存系統設計、程序語言對數據庫連接的處理、代理層功能，以及和二級制日志相關的數據管道的搭建，其中包括數據系統的分區、備份等設計。 >像以前，很多公司把所有的數據都放在一個數據庫里面，（我們最早也是這樣，全部放在oracle數據庫，oracle數據達到8TB，數據庫最大連接數3000），隨著業務不斷增長，開始出現各種各樣的問題，因為各種連接池和吞吐量的限制，基本沒有辦法進行擴展。開始設計數據標的拆分，將相關的數據放在一起，不那么相關聯的放在另一個庫，甚至放在了文檔型數據庫Mongodb中，逐漸緩解了可擴展性的問題。 >**隨著微服務的流行，數據庫也要進行拆分，無業務關聯的可以拆成不同的盡可能小的數據庫，程序可以通過dubbo接口去調用，相互獨立，相互不影響** **1.3、數據庫瓶頸** >配置過Nginx服務的小伙伴們都知道，當前端web服務流量增大時，只需要增加nginx的實例修改配置即可，但是數據庫出現瓶頸時可不一定直接添加實例就能解決的。 >只要是數據庫，就有吞吐量的限制，數據庫訪問瓶頸便是自然流量增長或者流量突增造成的，只要業務增長，總有一天數據庫訪問會達到一個上線。在這個問題到來之前，你需要進行各種垂直拆分或者水平擴展來提升整個上限（要做的工作很多的），或者你可以通過緩存如（CDN、nginx、redis）或者其他機制進行分流。 >例如流量突然暴增：可能是攻擊，也可能是進行了推廣活動，比如限時搶購、秒殺這樣的 攻擊我們需要提前做一些壓測或者訪問方面的緩存能降低數據庫的壓力。 推廣活動我們需要和業務產品運營溝通提前預案。 索引：不要過度依賴索引，無效的索引可能會更糟糕 事務：關聯事務、分布式事務，盡量拆成小的事務執行 **1.4、遇到的人為錯誤** 再好的系統，操作方式不對也是枉然，更何況并不是所有額工程師都是數據庫專家，所有人為的錯誤是最常出現的問題。 #### 1.4.1、人為錯誤可以分為兩種： >操作數據庫時候犯的錯 執行程序或者腳本犯的錯 #### 操作數據庫時犯錯的概率比較低，但是影響卻很大，幾乎所有公司都會有類似的傳奇事件，可以歸納這幾類； #### 1.4.1.1、 有意無意的刪除數據庫核心數據: >文章開始的例子也寫了，故意刪除公司數據，對公司會造成不可估量經濟損失，而且也會斷送自己的工程師職業生涯，也會面臨牢獄之災。 >操作數據庫時候失誤操作，要盡快恢復數據，盡可能挽回損失。很久之前，凌晨12點多操作數據庫（IT行業加班很普遍），進行刪除測試數據庫時候，不了心連上了線上數據庫，進行了刪除操作，執行完成就收到報警信息，瞬間頭腦清晰。慶幸的是恢復的及時，損失不太大，之后操作都改為早上5點執行，有異常能及時發現，（晚上操作完了有可能就去睡覺 了）。 1.4.1.2、 修改表結構誤操作： >工程師上線新版本，代碼中添加修改表結構操作，導致數據庫被鎖長達幾個小時，該業務線業務幾個小時出現服務異常。 工程師修改表結構不加where條件等操作，導致該表中數據被覆蓋掉。 1.4.1.3、索引問題誤操作： >在java的某個底層框架中，在初始化時候，默認有添加索引的操作，再一次預發布，上線測試中，導致線上數據庫直接被鎖數小時（環境隔離的重要性）。 某一個程序或者腳本中查詢沒有索引的數據，導致全表掃描，加上一些接口相互調用訪問，經常會出現數據庫的所有連接被占用的情況，導致查詢沒有辦法執行。 1.4.1.4、物理誤操作： >機房斷電、斷網，記得第一份工作時候，在公司機房上架、下架服務器，拔錯電源插頭，導致測試環境服務不可用（辦公室機房放測試開發環境，正式環境在運營商機房托管），雖然沒有影響線上業務，但是這件事時刻銘記在心。 #### 1.5、數據安全 >數據安全包括三個方面也就是：CIA(Confidentiality, Integrity, Availability) （1）保密性：不允許未經授權的用戶存取信息； （2）完整性：只允許被授權的用戶修改數據； （3）可用性：已授權的用戶可以對數據進行存取。 >物理安全：確保存儲物理設備安全，別被雷擊、盜竊了 防火墻：對數據庫訪問進行限制，例如允許那個路由訪問數據庫的端口 運維安全：對運維行為進行流程化管理，提供事前審批、事中控制、事后審計、定期報表等功能，將審批、控制和追責有效結合，避免內部運維人員的惡意操作和誤操作行為 數據庫審計：實時記錄網絡上的數據庫活動，對數據庫操作進行細粒度審計 數據加密：從技術角度對數據進行加密，通過數據加密能夠有效防止明文存儲引起的數據內部泄密、高權限用戶的數據竊取，從根源上防止敏感數據泄漏 漏洞掃描：通過數據庫和代碼進行漏洞掃描能夠有效的評估數據庫系統的安全漏洞和威脅并提供修復建議 數據備份：在數據庫出現異常情況，可以及時恢復，誤刪除，機房斷電導致數據損壞 ### **2、新手入行應該先學習哪個數據庫?** >推薦以開源MySQL為開始(80~90互聯網企業都在用，薪資相較OracleDBA要高一些(資本 集中)，上手相對容易)，mysql熟悉以后，任何的關系型數據庫系統都是相通的，掌握了MySQL，其他的關系型數據庫都不在話下 ，非關系型數據庫相對關系型都比較簡單，而且部分理念也相通。 **持續學習：** >其實不止是DBA，整個運維體系都在做轉變，傳統的玩法效率低、重復工作多，已經不適用互聯網公司高速度、快節奏的發展了，所以說DBA工作內容需要轉變，思想也需要轉變，應該向著如何快速交付、提高數據庫整體穩定性、高效率運維 、打造適合更多適合業務需要的數據庫產品方案，甚至給研發輸出數據架構方案等這些方面發展。 **數據庫前沿技術：** >例如DB自動化管理平臺 主機管理：主機增刪改、主機資源（cpu、disk、men） 實例管理：實例增刪改、實例主從切換 審計管理：sql審核、sql回滾 日志管理：binlog、慢查詢 任務管理：定時任務 日常維護：批量sql執行、配置修改、自動擴容 **目前北京DBA就業形勢：** >招聘待遇，月薪2w-3w的占比居多，達到50%-60%，經驗要求3-5年的居多。 **持續學習 只為認識更大的世界** 1.2.2