持續關注突發，資料庫運維應該關注哪些潛在風險？

• 2020 年 4 月 7 日
• 筆記

資料庫技術的發展變化是怎樣的？資料庫運維優化和設計要從哪些方面入手？如何實現業務自助和業務的高可用？本文是dbaplus社群聯合發起人，競技世界資深DBA 楊建榮老師在「雲加社區沙龍online」的分享整理，帶給從事DBA領域的同學們一些職業成長方面的思路拓展。

引言

正式分享之前，先對最近熱門的刪庫事件做一點反思。作為DBA應如何加強預防，改進措施防止再出現類似事件呢？我認為主要從三點出發：一是流程規範，二是技術支撐，三是安全制度。

之所以沒有把技術支撐放在第一點，是因為對於現在暴露出來的許多問題，更多是在流程和規範方面設計不合理，在完善整個流程和規範的基礎上，再做技術的補充。

從技術層面來說，一定要完善備份恢復體系。在現今的技術支撐方面存在一個短板，我們更多是在恢復單個環境，對於整個業務集群的恢復方面做得比較薄弱。

最後一定要完善安全制度，安全問題在工作中地位變得越來越重要。

一、技術變化

對於資料庫運維開發和管理相關的工作可以濃縮為四點：

第一是技術的變化。

第二是優化和設計。

第三保證業務高可用，我們需要提高系統整體的高可用，和業務結合起來做到真正的業務高可用。

最後是業務自助，尤其在疫情大背景下顯得更加重要，很多事情其實不需要太多的溝通環節，如果能夠做到自助化服務，整體工作的銜接會比較流暢。

以我入行時經歷過的一個難忘的坑說起。

同事很久交給我一套MySQL環境，我看到的是主從的環境，有一天收到一條報警，是從庫伺服器文件系統問題。我又仔細看了一下發現這個從庫竟然沒有開binlog，所以這是一個假的從庫，但是這個業務是關鍵業務，擺明是一個坑。

要修復這個問題，就需要重啟從庫的服務，需要重新搭建slave節點。本來以為重啟一個binlog沒有什麼大問題，但是發現資料庫停不掉，或者起不來，起來有一些業務回饋連不上資料庫，還有一些回饋的操作日誌顯示數據連接有異常，逐個做排查，發現這些問題都超出我們計劃之外，可謂是一波三折。

所以很多看起來很簡單，沒有技術含量的事情，在實際工作中，會碰到很多比較具體的問題。我們在實際的工作應用中碎片化，瑣碎化的事務會比較多，重複性也會比較多。

從技術的變化來說，我最早是做Oracle，逐步切換到MySQL和運維開發方向。經常聽到很多人評判一個資料庫哪一個好，哪一個不好，哪個大框架下更吃香。從我經歷了Oracle到MySQL過程，感受到的是技術在逐漸返璞歸真。

DBMS榜單是顯示整個資料庫的排行榜，可以看出Oracle、MySQL關係型資料庫排名穩定靠前，在這個過程中，一些NoSQL發展也很不錯。

我們以MySQL為例，大概十幾年前，從原來的Sun公司分離，之後到Oracle公司，MySQL有一個逐漸分裂的過程。

下圖列出了一些MySQL的組件服務，十多年之後，可以看到一些從屬引擎已經被替代了，有一些被放棄了，而一些像innoDB引擎在Oracle官方支援下不斷加強。

所以技術是在不斷迭代，不斷的演進過程中，而歸真的部分是你會發現原來在互聯網如火如荼的MySQL，在走入8.0版本之後很多功能都開始和Oracle的設計有相似之處，所以風水也是輪流轉，很多問題不是單純的技術問題。

二、優化和設計

關於對資料庫的優化，主要體現在優化思維的轉變。

早些年會大量對SQL進行分析優化，因為原來的業務場景比較複雜，導致很多的SQL寫得比較長，有時能達到幾百行，整個邏輯關係比較複雜，需要優化。

但是在現在互聯網場景下面，這樣的場景開始減少。原先的優化思維是要做得更多，但現在更多要求做得更少，直至達到至簡設計的要求。

舉一個例子，我們之前有個業務是做商業資料庫遷移到MySQL，原先它的QPS是50萬，我們把服務的負載進行分散式改造，改完了以後QPS變成了2萬。從50萬到2萬，它的性能反而更容易擴展、更穩定。

我們原先是希望支撐更多的QPS，但是發現通過這樣一個邏輯改造，做得更少的情況下，能夠更好地滿足原來場景，這就是在優化思維層面上比較大的轉變之一。

現在複雜的SQL變得越來越少了，為了保證技術和業務的兼容性，很多業務的調用都在儘可能做到至簡。

設計更多也需要從系統層面考慮，大家經常會關注千萬級大表的優化方式？其實對於千萬級大表的優化，可以拆成三個部分對待：

• 數量級：千萬級
• 對象：數據表
• 目標：優化

千萬級大表做優化過程中，一方面需要了解數據表的屬性，針對不同的屬性，需要在不同的層面做相應優化。在這個過程中，SQL優化和索引的優化只是資料庫優化過程中的一個相對較小的一個環節。

業務上的表主要有三大類。第一是狀態表，也就是OLTP表，狀態表數據相對來說比較穩定。第二是流水表，狀態隨著時間的變化發生變化的一些行為就叫流水表，像日誌等等都是流水表。第三就是字典表，用於配置通用業務，核心思路是要配置得小而簡，避免所有配置丟到一起。

在明確這樣的基本概念下，再來看整體優化，比如一些規範的設計，需要在業務層優化，對業務不斷做拆分。架構層更多要和業務結合起來分析業務的具體使用場景，比如是在線業務，離線業務還是統計分析業務等等，根據不同場景做相應優化。

千萬級大表做優化需要考慮架構層和業務層，架構層可以使用中間件技術實現讀寫分離，包括負載均衡相關的技術，從兼容角度，可以參考HTAP相關概念，兼容TP和AP的業務，架構並不局限於MySQL，要選擇適合的場景。

從業務層來說，使用場景也有很多業務考量，比如業務拆分，把一個混合的業務拆分成一些獨立的業務。包括表裡面的狀態、歷史數據都可以做分離。比如對數據拆分，可以按照日期拆，也可以按照分區模式拆等。

相關的表，可以理解跟人的性格一樣，一些業務場景可能是讀多寫少，另一些是讀少寫多。這意味著單純使用MySQL肯定有瓶頸。讀多寫少應儘可能和快取結合，例如現在很多直播技術是基於快取的基礎。對於讀少寫多場景，有一些使用業務提交或者隊列技術。還有降低寫入的頻率，比如原先寫入的頻率是每十秒鐘更新一次，如果從業務場景來說，允許改造成一分鐘更新一次等等，這樣一些使用的方式都可以對千萬級大表實現優化的效果。

現實很多工作中還會涉及到極限的優化。比如我們之前做了一個大型分散式集群，做核心業務線的發布。原來的延遲是在1.5毫秒，寫的延遲在5毫秒以內，以整個集群狀態來看，讀的延遲是不滿足當時的上線標準，寫的延遲勉強夠。

在這樣場景下進行毫秒級的優化，我們準備了一個密集壓測的環境，不斷調整和迭代優化方案。最終從1.5毫秒逐步演進到0.68毫秒，寫延遲從5.0毫秒，逐步演進到2.7毫秒。這個過程涉及到整個系統架構，包括對一些SQL邏輯的調整，在細微變化中，我們把整個延遲逐步控制在一個相對比較理想的狀態。

其實很多業務中對於備份恢復的關注是不夠的。備份恢復可以用來做什麼？通常在我們理解中備份是靜態的，靜態意味著對業務來說是不可見的，不可見就意味著不可用，對很多公司和業務看來有一點「雞肋」，但是備份恢復在沒問題的時候看似沒有什麼用，但是出了問題就變得相當有用了。

換一個思路，可以試著從另外一個角度構建出來可以折騰的備份。折騰的意思就是我們對於業務的誤操作可以做到數據的閃回，例如對五分鐘之前的一個操作，可以很快做恢復，而不用做全程的恢復。

比如業務測試數據，線上業務如果做增持的壓測風險很高，如果需要在完全對等的數據量的環境下做壓測評估，可以通過備份恢復環境評估真實的模擬，有點類似租戶一樣，用完了以後可以釋放。

備份可以從快照方式理解，整個設計思想就是一次全量，永遠增量。達到這樣的目標之後，無論是存儲的空間、備份的效率都會變得更加理想。

三、業務高可用

對於冷熱數據的分離，可以根據binlog數據的抽取實現數據的閃回。

現在大家更多考慮的是系統和資料庫層面的高可用，而很少關注整個業務的高可用。舉個例子，有一個很重要的真實場景業務，大概800級的數據量，需要我們整個壓測模擬做完後構建一套新的數據服務，但是整個數據的遷移到切換沒有統一的維護窗口，如何實現平滑的數據遷移和整個業務的切換呢？我們設計了如下的方式：

第一是是旁路的概念，原來已有的數據服務，和一個新的數據服務做相關的重構，需要經過一個架構，將已有的數據服務打開，把新的數據複製上去，這樣業務就會打在新的數據服務上，再在新的數據服務上做數據遷移和數據集合等一些服務操作。

到了正式切換的時候，先做一個全量的遷移。比如準備早上十點開始做一個完整遷移，下午三點完成。早上十點到下午三點期間的增量數據怎麼同步呢？就需要進行增量的同步和在線的集合。

把原來數據旁路的服務停掉，做完了全量同步之後，再做增量的同步，在這個過程中產生的數據量相對800量級來說比較少，也會比較快。比如增量用時10分鐘，這樣三點到三點十分這10分鐘之內還會出現一個增量，這個增量該怎麼做呢？那就做在線稽核。

所以整個數據的追平使用增量的同步和在線稽核補充，然後不斷做數據比對。比如做冪等查驗，把上面數據覆蓋成新的數據服務的數據，達到整個數據完全追平在線稽核。之後再把真正的寫流量遷過來，原有上層的入口服務流量這一層調度的時候會把已有的服務和新的數據服務寫一份，對業務來說，讀取會更直觀。

如果已經驗證完成之後，再通過上層的分散式集群服務，將上層的流量切換到新的數據服務上，即使是出現問題，也可以實現快速的回退，把流量從上一步切換過來。因為這兩端數據是冪等性的設計，所以這一個過程可以不斷做增量和在線的稽核。

四、業務自助

對於業務自助，其實是一把「雙刃劍」，對於後端服務來說，可以節省時間，很多的不必要的溝通和協調可以通過自助的方式解決。對業務來說，也不用做額外的溝通，整個過程中，可以提供相關的一些自助服務。比如SQL自動化上線，SQL自動化審核，慢日誌平台設計優化等等。

我們日常的思維習慣是先看一些近期的慢日誌性能情況，SQL最近運行情況，有什麼樣的瓶頸，然後分析出哪一些SQL是應該重點關注的，哪一些需要做優化，然後提取SQL相關數據，逐步優化。

整個思維習慣我們可以用潛台詞「彙報」的思路做一些闡述。比如查看慢日誌，為什麼查看？就是想確認有沒有問題。如果有問題我們想確認這個問題嚴重不嚴重。我需要更多關注哪一些SQL，更關注哪一些問題？對於這些關注的問題，我們有什麼樣的一些建議和解決方法？所以從慢日誌的優化來說，有相應的一些業務自助設計。

有沒有問題？我們可以通過趨勢圖分析，比如CPU負載高了，基本上是SQL的性能比較差。問題呈現可以通過分數可視化的方式，這樣對於使用者會有直觀的感覺。

也可以通過概覽的方式把這些問題概要列出來，把這些SQL做一些分組和聚合，提取出一些關鍵的點。然後分辨哪一些問題是需要重點關注的？再通過相關明細的資訊。比如索引、欄位、表格的設計等等可以得到更全面的分析給出相關建議。一般來說都會存在二八原則，優化掉20%的問題，會達到80%的收益。

如果要看一些更明細的資訊，比如需要添加縮影，看SQL的明細，對於每一個SQL可以生成明細的圖表，SQL完整語句是什麼樣，SQL歷史的執行和執行時長也都可以看到。

優化中經常會看SQL執行計劃，比如走了「圈表」，在什麼地方走「圈表」，這個表涉及到哪一些表，展開看到表的欄位和設計。有時候我們優化這個SQL之後發現其他SQL也產生問題，因為我們做的是單一的優化，沒有更全面的分析，所以可以引入相關的SQL優化。

這些表優化以後，可能會對下面的SQL也產生影響。整個優化過程中，可以不斷的做對比，看潛在的SQL有沒有受到一些影響，在優化的時候可以並行把這樣的SQL關聯評估一下。

整個工作當中，像業務自助，優化設計，包括業務高可用等技術，很多都不是單一的，而要用從全面的角度、更綜合的態度出發解決問題，不是會什麼技術就一定要用什麼技術，而是根據適合的場景做相應的評估和設計。

在這個過程中，會發現積累很多問題，對這些問題的解決會逐步形成自己的一個知識體系。我們需要構建自己的知識體系，處理各種問題的時候，會碰到很多的資訊，可以把它們做歸納和梳理，最後可以得到相應精華要點，沉澱出一些真正有價值的知識。

五、結語

其實做資料庫運維、開發相關的工作，日常任務碎片化程度比較高，很容易抓不到重點。在這個過程中，也會讓很多人變得浮躁，沉不下心來。所以我們要選擇對自己比較有利的方向不斷梳理和總結，形成你自己的理解，沉澱屬於自己的真正有價值的知識體系。

我最後為大家分享一下我自身職業沉澱的整個過程？我大概是在2014年開始寫部落格，最初的想法是為了解決問題，比如Oracle出了問題，解決之後過了一段時間又遇到這個問題，但是之前解決的過程卻已經忘了，又得重新花時間解決了一遍，後來我就把這個過程完整梳理一遍，用文章的形式將操作過程整理出來。

當然一開始只是為了便利自己，積累到一定程度之後，有很多朋友看到了我的一些部落格內容，他們可能也會碰到類似這些問題，但最終解決的背景和步驟並不一樣，很多問題也是通過和大家的交流，不斷擴充得到的，整個過程開始從一個利己的事情變成利人的事情。

再達到一定的沉澱之後，我發現處理很多問題和案例都存在一定的共性，經過不斷的梳理，最終形成一整套知識體系。這也是我寫《Oracle DBA 工作筆記》這本書的初衷，所以我覺得很多事情都貴在堅持，在你堅持總結的過程中，你會發現這樣的過程對自己益處會相當大。

六、Q&A

Q：監控平台是內部研發的嗎？

A：這個平台是內部研發的，我們整個設計是基於前後端分離的方式，後端做一些API介面的設計完善，前端做了一些可視化的渲染。

Q：請教一下如何快速的修復語句，是在線修復，還是有什麼樣的優化體系？

A：在線修復第一種是SQL，它不是冪等的，比如說做一個RB Date，是有時間維度，這個基於維度可能不需要做恢復，可能通過語句性做密等恢復。比說Delay沒有做，整個表刪了，改錯了，這個做閃回是比較熱的binlog，其實做在線SQL的提取，這個層面做在線修復，都是比較快的。

Q：千萬級或者是億萬的表有什麼好的歸檔方式呢？這些表是每時每刻都有大量的DML？

A：首先對於數據量我們定義是千萬級，或者億級甚至更高。有什麼好的歸檔方式呢？其實提到歸檔的方式，按照我的理解更多是屬於流水表，流水表的歸檔方式在設計中可以參考很多拆分的體系，通過日期的方式拆分，或者通過分區的方式拆分。如果通過日期的方式拆分，相對來說比較方便，你歸檔的時候，比如說用日期表換月表，日期表是10月21日，11月21日的時候可以把10月21日的表直接歸檔，歸檔推到大數據或者是推到數倉，你推送之後數據下沉之後可以直接召回，不涉及到資料庫Delay操作。

如果表每時每刻都有大量DML，這個DML也可以拆分。如果你的千萬級或者億萬的數據量依然有大量的DML，建議考慮其他的架構設計方案。包括考慮業務拆分這一層。目前來看億萬級使用NoSQL可能會是比較好的方式。

Q：怎麼從零搭建資料庫運維繫統？有什麼好的開源工具推薦？

A：資料庫運維管理系統搭建涉及到幾個方面。運維開發層面著重於怎麼構建資料庫運維體系。首先你需要具備一定的運維開發的能力，從零搭建的程中，個人迭代代價比較高，開源好的工具比如Ops Manager，在此基礎上做迭代，逐步做前後端分離。

在這個過程中，需要考慮前後端分離怎麼在運維繫統中更好落地？對於很多運維，如果你具備後端開發能力，但是前端開發能力不足，怎麼把短板補上？主要是做前後端分離，後端通過API進行集成，這樣可以少一些困擾。

Q：對慢日誌平台這一塊很感興趣，可以聊聊這個工具的架構和思路嗎？

A：慢日誌平台，開發工具我們是基於Python，你用shell開發都可以。

架構方面，整個平台設計，分為慢日誌採集，慢日誌分析，慢日誌模型，最後是前端的渲染。慢日誌採集有不同環境，不同的IDC服務，我們可以在不同IDC生成一百套慢日誌，我們都提取出來到分散式節點，把一些慢日誌提取出來，提取匯總到一個服務節點上，在這個服務節點上使用PT工具對慢日誌做分析，我們做的分析就是基於原始的分析，把SQL提取之後，把數據上傳到運維繫統，通過API方式上傳，在運維繫統裡面定義一些模型，比如快照、日誌、慢日誌個數，定義快照的表和模型，排行榜也有這樣一個模型，包括時長分布，詳情等等都會有相應不同的表設計，包括像一些明細都是一套完整的設計。

優化建議這塊是可選插件式服務。比如對於優化建議行業里也有這樣一些比如SQLWhether可以做基礎優化建議，可以把這塊做集成。

包括做執行計劃和表的欄位等等，執行計劃是在線採集出來的，在慢日誌本身不體現。像結構資訊，如果你公司的表設計有版本管理、生命周期管理，可以直接從裡面提取出來這些結構的資訊。如果沒有也可以實時採集這些資訊，這些資訊可以基於模型裡面做關聯，關聯後就可以分析出來了。

整個的模型做完了之後，再和前端做對接，有一些相關的API對接。像CPU趨勢圖完全是監控的數據，我們把監控數據提供相應的API，根據相應時間維度提取，提取概要的數據，然後可以做相關的分析，看和CPU負載有沒有關係等等。

採集工具開發其實對於開發語言沒有嚴格的限制，我們可以用Shell也可以用Python，我們當時使用的是python。

Q：數據整體遷移到新平台時除了考慮安全性，還需要考慮什麼？

A：數據遷移到整個新平台，其實不光是需要考慮安全性，其實更多是有兩層的考量，有技術層面的考量，有對整個業務層面的考量。

比如說原來用的商業資料庫，其實使用開源技術是大技術趨勢方向。另外就是更多引入一套分散式的設計，分散式設計儘可能落地推廣，大體是這樣。在這個過程中，比如說也有很多的策略，我們原來業務有很多是耦合的，比如說實現一些同步的方式，同步過程中一旦有阻塞，整個是一個鏈式的影響，實現業務的方式以後，可能按照系統的設計包括架構設計相對來說會更有彈性。真正基於一些綜合的考量，不光是一些安全性，包括像一些擴展性，比如說原有的集中式管理服務，比如說你服務的壓力負載容量擴兩倍、四倍，原來的負載是不是能支撐。基於分散式服務是不是能更快做擴容和縮容，這個也是考慮相對來說長期規劃的過程。

Q：索引截圖那部分是採集平台展示的方式，還是人工上傳的？

A：整個索引部分其實剛剛說了，如果你有生命周期管理，或者有一個版本管理，你可以在自己模型或者數據級裡面提取出來，如果沒有的話，可以進行實時採集，展開以後可以看到相關索引的資訊。

Q：慢日誌排行榜和慢日誌時長分布的時間維度是？

A：慢日誌排行榜其實做了慢日誌生成，有時間維度，比如1點到3點，2點到3點，這個時間報告是不一樣。我們生成這個維度採集的頻率是30分鐘采一次。

Q：可以做到對這些SQL黑名單做攔截嗎？

A：對這些SQL做黑名單攔截，可以使用審計的插件實現。如果作為SQL黑名單這個顯示做攔截，其實在模型層指定的時候做一層過濾就可以。

Q：資料庫如何查詢死鎖資訊，並快速定位死鎖的故障？

A：首先資料庫裡面默認是有一個死鎖的參數，大家如果用5.7以上的版本，默認會把資料庫死鎖的日誌都打到資料庫的errorlog。如果更快速定位這個死鎖的故障可以用兩種方式：

第一可以通過把這個資料庫的日誌對接到ES裡面做死鎖的檢測，更快速。

第二可以做相應監控巡檢的方式，把這塊資訊綁定起來。

Q：對於初入行數據運維職業發展有什麼建議？

A：如果你想入行做DBA，首先要對某一個資料庫非常感興趣，你需要不斷鑽研這些技術。從技術發展來說，技術的變化一定是非常快的。

先把一門技術做得精通，然後再去逐步的擴展你的知識範圍。因為倘若熟練掌握這個技術以後，再學習其他的方式相對來說會比較快。關於職業發展，我覺得需要踏實一點，你碰到一些問題，需要總結梳理出來，形成自己的知識，這樣對你後續的職業發展會有很大幫助。

Q：從Oracle轉MySQL跨度難嗎？

A：從技術來說跨度難度不大。因為Oracle整個體系相對來說是比較全的，你在學習MySQL的時候，會發現很多的問題理解起來說比較容易的。MySQL轉Oracle相對來說比較難一些，但是MySQ其實會有更廣闊的想像空間。包括在架構層面，MySQL在高可用架構等等這樣一些服務的層面，它的社區紅利還是非常不錯的。

很多人為什麼覺得轉得特別難呢？通常是因為工作當中沒有那樣的環境，不管你怎麼迭代，或者是自己做這樣一些練習，跟真實的環境處理還是有一些差別的。所以要從從心態上做出轉變，要堅持下來，當然這個過程中你也要做很多方面的調整。

Q：已有數據服務和備用數據服務的數據同步和校對有什麼實現方式？

A：其實對於表的設計來說，首先它不是一個一鍋燉的業務，對於業務來說首先是密等性，從業務模型來說首先一定保證整體設計思路是對狀態表的服務做同步和集合。在這個時間段之內，做增量同步的時候，其實一種是根據時間做的。原來是200，我們在這個時間段之內增加100，再做增量的時候，其實會把它的狀態從200變成300。然後如果在這個過程中，實時發生變化，我們會拿這個數據和線上的數據做一個在線的集合。在這個時間段之內不斷做集合，集合確認數據是正確的，如果是不正確的，我們會把這個線上的數據覆蓋過來。

數據同步這塊有比較多的方法，你要提取的方式，因為數據量非常小。比如說基於時間的維度提取，可以根據這個差都可以提取。另外提一下，我們這個在線同步是基於快取持續，我們不是直接對線上直接做同步，而是在第三方有數據同步的方式，會把這個數據放到池子，通過數據隊列方式把這個數據進行消費。這個過程同步的過程不要影響已有的服務，同步完了之後再做線上集合。

講師簡介

楊建榮，dbaplus社群聯合發起人，競技世界資深DBA，騰訊雲最具價值專家（TVP）。前搜狐暢遊資料庫專家，Oracle ACE。具有十多年資料庫開發和運維經驗，目前專註於開源技術、運維自動化和性能調優。《Oracle/MySQL DBA工作筆記》作者，每天通過微信、部落格進行技術分享，已連續堅持2100多天。

關注云加社區公眾號，回復「在線沙龍」，即可獲取老師演講PPT。