1 前言

轉轉是PingCAP最早的一批用戶之一，見證了TiDB的發展，自身也沉淀了不少經驗。

從1.0 GA開始測試，到2.0 GA正式投產，然后升級到了2.1，后來又升級到4.0.13，最后建設自動化平臺。

其實轉轉DBA團隊初建以來就開始投入一定的資源進行平臺建設，一步一步實現自動化運維，希望一切需求都能實現工單化、一切操作都能實現平臺化，進而降低人力成本。

本文就想來分享一下TiDB實現自動化的歷程。從遇到問題開始，到解決問題，以及平臺做成什么樣，也是對過去的工作做一個總結和梳理。

2 運維痛點

（1）轉轉現有集群30多套，早期都是2.1.[5,7,8,17]版本，近500個TiKV節點，總共差不多一百臺機器供TiKV使用，集群新建、擴容、遷移都需要人工找機器。也因為缺少一個上帝的視角去管理集群，沒法做到資源的合理分配，導致日常工作中有很大一部分時間都是在做遷移，都是重復工作，效率很低。

（2）2.1版本的運維工作都是基于Ansible進行。如擴容、下線、啟停、修改配置等日常操作，有時候會碰到Ansible執行超時的情況。批量操作集群時，根本不知道到哪個節點了，這情況經常能遇到，在reload集群配置文件的時候遇到的概率就非常大，要多崩潰有多崩潰。

（3）2.1版本的TiDB自身有很多問題，執行計劃失效、讀寫熱點問題（不能快速定位問題）、TiDB大查詢OOM、樂觀事務、監控不完善、以及已知/未知的問題，就連集群狀態都無法快速獲取，當然備份也很痛苦，這對運維人員的工作加大了難度，也提升了人力成本。

4.0 使用悲觀事務需要滿足一定的要求，具體請參考官方文檔。

（4）機器資源使用不平衡，存在部分機器內存剩余較多但是磁盤不足，還有部分機器內存不足，但是磁盤剩余很多。導致的結果是老板覺得機器投入已經很大，但是DBA實際使用中發現機器還是不夠用。

（5）告警噪音比較多，存在重復告警，互相沖刷問題，嚴重浪費告警資源，對排查問題也帶來很不友好的體驗。

3 解決痛點

3.1 元數據管理

將所有節點信息保存到表里，定期采集節點狀態及資源使用情況。

過去都是依靠Ansible的配置文件進行管理，管理視角基本是停留在集群都有哪些節點，連一臺機器都有哪些實例都不清楚，更別談資源管理了。

現在將所有組件保存到一個表中，定期采集組件服務狀態，內存磁盤占有量等信息。這樣就有了一個全局的視角進行管理，也很方便的查閱集群狀態。

后續基于這份元數據進行項目成本核算。

還有一個收益就是，組件信息的采集，可以很好的控制單個TiKV的容量，不會再出現單個集群容量一直增長，然后觸發機器的磁盤告警DBA才感知到。有了這個采集的數據后，可以設置一個TiKV容量上限，比如500GB，達到這個閾值就發送告警給DBA準備擴容。這樣能很好的避免因機器磁盤告警而接收大量告警信息（單機多實例），也能提供一個很好的緩沖時間讓DBA來處理。

總結起來就是，能很好的將機器/集群/組件管理起來，能合理有效的進行資源調度，也為實現自動化提供了基礎數據。

3.2 機器資源管理

將所有機器信息保存到表里，定期采集硬件資源使用情況。這么做能獲得如下兩點收益：

• 第一是對已有環境進行rebalance。有了元數據信息，就可以很好的展開rebalance工作了。最終收益很明顯，既提高了資源利用率，還降低了15%的機器資源。
• 第二是能合理有效的進行資源調度，為實現自動化提供了基礎數據。（同元數據管理）

元數據管理和機器資源管理，這兩部分工作既降低了成本也提升了工作效率同時也是監控的兜底策略，會基于這兩個數據表進行監控：（1）進程是否正常。（2）機器是否正常。

3.3 全面升級

將所有2.1集群升到4.0.13。

為了更好的管理集群，在升級前還做了一些規范化。第一是端口規劃，因為TiDB組件太多，一個集群至少需要6種組件，涉及到十多個端口，所以做了端口規劃，端口采用2+3的格式，前兩位表示組件名，后三位表示集群編號。即：前兩位一樣表示同一類組件，后三位一樣表示同一個集群。這樣就可以很好的實現規范化管理。

比如有一個001編號的集群，集群信息如下：

• 我們每個集群的監控告警都是獨立的組件，原因是在使用Alertmanager過程中發現有時候A集群的告警信息的instance的值是B集群的instance，為了避免出現這種問題，我們每個集群的監控告警組件都是獨立的。
• 另外我們會提供5個域名，分別對應到TiDB對外服務，Dashboard，Grafana，Prometheus，Alertmanager。
• 僅需要提供集群編號，就可以快速獲取各組件的端口號及域名，看到部署目錄就可以知道是哪個集群的哪個組件。
• 需要注意的是，如果將Dashboard暴露給業務使用（業務很喜歡訪問慢查詢平臺），建議是創建獨立的賬戶，因該平臺強制要求使用root，所以可以針對PD組件的幾個機器單獨創建root賬號，這個root的密碼跟DBA使用的root進行區別?？梢员苊夤芾韱T賬戶泄露的問題，但是帶來新的問題就是賬戶管理變得復雜了。

全部完成升級后。整體性能提升30%-50%，解決了抽數帶來的影響，升級以后暫時沒有收到因抽數導致影響到業務的反饋，在升級前幾乎每兩個月都會有至少一次因為抽數導致業務受影響。

3.4 告警改造

支持短信、語音告警，并實現告警收斂、抑制，告警升級。大大降低告警條數（條數至少能降低60%），節約告警資源。

收斂和抑制目的是降噪。

告警升級主要是為了降低告警成本，升級分如下幾個維度：

• 第一：介質升級。郵件 --> 企業微信 --> 短信 --> 電話（同一個告警項發送超過3次就向上升級一個介質，具體可以根據需求定義）。
• 第二：接收人升級。一級 --> 二級 --> leader。
• 第三：按照時間升級。工作時間通過郵件/企業微信發送告警，工作時間之外通過短信/電話發送告警。

詳情請看這篇文章 https://mp.weixin.qq.com/s?__biz=MzIwMjk1ODMzMw==&mid=2247487848&idx=1&sn=0a6f76ca4f8f44c8fcd9b34be3c0f07b&chksm=96d7e5faa1a06cecf916141897b3faad11f93f3899c6d21ef24e09414a23cb035ae7670334f2#rd

4 實現自動化

分布式集群有很多優點，但是對DBA來說也增加了運維復雜度，有些集群幾十上百個節點，全靠人工去管理運維無疑是很痛苦。

轉轉現在基本完成了自動化，收益也很明顯，這部分主要是想分享一下注意事項或者遇到的問題，僅供參考。

4.1 需求工單化

這部分主要是在平臺通過工單的方式實現了業務的日常的需求，降低了溝通成本，實現了業務需求審計，還能減少DBA的工作量。

目前支持如下工單類型。

工單類型

（1）集群部署工單

在4.0版本中，部署一個新集群比較麻煩的是拓撲文件的生成，倒不是有多復雜，而是因為一個集群的組件太多，每種組件對硬件的要求又有些區別。

比如Grafana，Alertmanager這種不需要IO，PD，TiKV，TiFlash對IO又要求比較高，另外還需要根據服務的重要程度進行合理的規劃，重要的服務單獨部署或者盡可能的減少節點數，需要考慮的點參考維度有點多。

以上只是針對部署集群需要關注的點，還有一些額外的考慮點，或者說操作細節。總結起來如下：

• 為各個角色選擇合適的機器，完成拓撲文件，然后部署集群。
• 初始化集群，創建業務用戶，業務域名。
• 配置Grafana，Prometheus，Alertmanager，Dashboard等平臺，創建必要的用戶，以及Grafana，Dashboard權限控制，以及功能驗證測試等。
• 集群信息入庫，將必要的信息同步到業務側。

所以實現工單化，不僅輕松解決資源調度問題，提升機器資源利用率，還可以大大提升效率，避免操作出錯或者遺漏。尤其是功能驗證，萬一業務上線以后才發現問題，影響面就比較大了。

新建集群

通過sic判斷集群重要等級，預估QPS，TPS作為輔助參考項，最終根據評分為其分配合理的機器進行集群部署。

（2）數據恢復工單

這類需求在工作中倒不是很多，但是一旦遇到就會比較緊急。實現這類工單后，不僅可以降低溝通成本，降低故障的影響時間，也能降低人力成本。

目前支持兩個維度的數據恢復。

• 一種是基于快照，如果恢復需求的時間點在GC時間之內的，就直接通過快照進行數據恢復，所以這類需求恢復速度較快。
• 一種是基于備份文件，如果恢復的時間點位不在GC時間之內的，就只能選擇最接近該時間點的備份文件來恢復了。

目前這兩類維度都支持整庫（一個工單僅限單庫），單表或者多表?；诳煺盏倪€支持帶特定條件，基于備份文件的不支持帶條件。所以相對來說基于快照的復雜一些，特別是多表需要恢復到某一個時間點，且是帶條件恢復（單表部分數據）。

比如一個訂單，涉及多個表，需要將多個表某些訂單號的數據恢復到特定時間點。

由此可見，基于快照的恢復是比較靈活的，用戶可以選單庫，或者單表，還可以選擇多表，由于我們并不知道用戶需要恢復幾張表，所以帶查詢條件的邏輯應該是動態的，即當用戶選擇了某個表，就會彈出改表的查詢條件輸入框，有幾個表就有幾個輸入框，根據提示輸入到對應的表即可，如下圖所示。

數據恢復

（3）TiCDC工單

轉轉公司有一種特殊業務需求，需要將業務的數據抽取到大數據平臺，主要是給業務提供經營數據分析、用戶行為和畫像資產沉淀以及一些趨勢預測。

如果是MySQL直接做一個專門提供數據抽取的從庫就行了，但是TiDB不行，雖然可以暴露一個TiDB節點給大數據進行數據抽取，但是本質上還是對同一組TiKV進行操作，所以抽數操作很容易引起業務的抖動。

現在我們提供了兩種方案給業務進行選擇，優先可以選擇TiCDC，如果TiCDC不能滿足的情況下可以使用TiFlash。

ticdc

對于已經存在cdc任務，只需更新配置即可，另外需要注意下游如果是kafka的話，數據包的大小，要求跟kafka的最大值配置一致，否則可能會報錯，尤其是TiDB端擴大表結構的場景。

對我們來說，TiCDC需求真的太需要實現工單化了。那些需要抽數的業務，幾乎新增一個表就需要更新TiCDC的任務，之前都是郵件溝通，如今實現工單后，對業務，對大數據團隊，又或者是DBA都是十分方便的，降低了三方的溝通成本，提升工作效率。

（4）TiFlash工單

需求同TiCDC工單。

tiflash

從成本上考慮，TiCDC不需要額外的存儲空間，所以更優，也更受歡迎。但是存在一定的風險，比如TiCDC到下游的同步鏈路出現問題（上游TiDB業務進行調整可能會導致同步中斷），那么下游就會無法獲取增量數據。

TiFlash則不會有這個問題，但是需要犧牲一定的存儲空間，業務成本會有所提升，需要業務自己去權衡。

4.2 操作平臺化

這部分主要是在平臺通過頁面操作實現了日常的管理，降低了運維成本，實現了操作審計，還能避免一定的人為操作失誤。

（1）節點管理

這部分涉及節點的啟動、關閉、重啟、下線、維護等。節點啟停、重啟流程比較簡單，這里不做過多介紹。

節點管理

只有當節點處于關閉狀態才會有啟動選項。另外需要注意的是，重啟操作已經改成reload，這樣對業務的影響相對小一些。前提是要評估好restart是否等價于reload（沒有變更配置基本不會有什么問題）。

下線和維護操作需要注意如下幾個事項：

節點管理

• 下線的目標節點是否是該角色的最后一個節點，或者是否滿足raft協議的最低要求，如果是則不能直接下線，需要人工介入。
• 維護操作主要是需要聯動一下告警靜默，因為維護操作本身是計劃內操作，對于不必要的告警可以提前規避掉。

對于PD，TiKV等組件對數量是有要求的，PD，TiKV最少要求兩個，所以當集群只剩兩個節點的時候是不允許下線的，需要DBA介入操作，當然還有DM-worker，TiFlash等組件也是有最低數量要求，需要根據實際情況進行判斷。

（2）擴容管理

擴容分兩種情況，一種是主動擴容，一種是自動擴容。這個小結是介紹主動擴容，至于自動擴容后文會介紹。

擴容功能比較靈活，支持多角色同時擴容，節點個數可配置，目標地址也可配置，如下圖所示：

擴容

未指定地址的話就由系統默認分配合理的目標地址。

（3）下線管理

下線要求是串行操作，即一個集群在同一個時間只能有一個節點被下線，等待下線后才能下線第二個節點。另外，如果是存儲節點（TiKV，TiFlash，Pump），需要等待數據遷移完畢后，執行完集群調整（prune）操作才算下線完成。

下線

需要考慮一下異常節點的下線，即機器宕機不可恢復的情況，所以我們增加了一個強制下線的選項來處理此類異常場景。

（4）告警管理

告警跟運維工作息息相關，一個好的告警管理平臺不僅能提升運維的效率，還能提升工作舒適度及生活質量。

我們的告警管理平臺現在功能比較簡單，后續會慢慢豐富。

• 支持預先配置告警靜默，比如將對某個集群進行維護，可以先將該集群的告警進行靜默。

告警管理

靜默時間最長不允許超過24小時，默認是2小時，這樣可以避免因遺忘導致該告警項被長時間靜默。

• 支持針對已經告警的項進行靜默。這部分邏輯是將所有告警項展示出來，供用戶選擇。

如下是正在告警列表展示頁

告警管理-告警列表

支持一鍵靜默，即：正在告警的項全部靜默。

如下是靜默規則列表展示頁，正在運行的靜默規則支持刪除及禁用，禁用狀態的允許重新啟用。

告警管理-靜默規則列表

（5）慢查詢告警

這個功能是統計單位時間內慢查詢條目增長量，當達到告警閾值就會觸發告警，用戶可以設置統計的時間范圍，以及慢查詢閾值，還有告警閾值。

慢查詢告警-添加規則

集群的慢查詢閾值大于用戶定義的規則的慢查詢最小閾值，會將集群的慢查詢閾值設置為該閾值。如集群慢查詢閾值是300ms，用戶定義告警閾值是200ms，這時候會將集群的慢查詢閾值設置為200ms。

如下是規則列表展示頁，支持規則禁用及刪除，禁用后可以重新啟用。

慢查詢告警-規則展示頁

4.3 其他輔助功能

（1）進程監控

進程監控

因線上機器基本都是單機多實例，有時候會出現因為某個實例而影響了整個機器的性能，在沒有進程級別的監控下，對我們排查定位問題十分痛苦，為解決這一個痛點，我們開發了進程維度的監控系統，這樣可以很好的協助運維人員排查定位機器資源跑滿等問題。

進程級別的資源監控，包括但是不限于CPU, 內存, 磁盤IO, 網絡流量，功能還在繼續豐富。具體實現可以參考這個文章 https://mp.weixin.qq.com/s?__biz=MzIwMjk1ODMzMw==&mid=2247487654&idx=1&sn=0722b7e216cb2f887eea2d8f874faa88&chksm=96d7e434a1a06d22b2a52a87b4bcc8a2fbc52218802ceefa6f243a0bb71a0ea02fd521c67395#rd

進程監控

會記錄每個進程的資源使用情況，其中網絡數據是做了限制，只有達到閾值才會采集，所以會出現空白頁情況。另外網絡傳輸數據會記錄源端到目的端信息。

（2）趨勢監控

隨著時間的推移，業務數據也在不斷的增長。那么問題來了，這個增長是否符合預期？按照這個增量，磁盤空間能支持多長時間？為了解決這兩個問題，我們采取了趨勢分析的方案，提前監控，分析增長趨勢，對于增長異常的集群會和業務進行溝通確認，對于磁盤空間臨近告警線會提前遷移。

進程監控

• 增量告警，當數據目錄在三日內連續單日增長超過20GB，每個月增量超過200GB就會發送告警給業務，請業務進行確認。
• 全量告警，當數據目錄達到告警閾值就給DBA發送告警。

（3）自動運維

• 自適應遷移

當機器準備達到內存告警閾值，磁盤告警閾值，就自動遷移。

• 自適應擴容

當單個TiKV容量達到800GB就自動進行擴容。

不管是自適應遷移還是擴容，都可以減少DBA的工作量，也能在一定程度上減少告警量。對于擴容，既控制了單個TiKV的大小，對于系統性能也會有一定的提升。

單節點TiKV太大，不利于管理。在節點下線的場景下會拉長數據遷移的時間，在節點離線的場景下，會拉長生成新副本的時間。

5 寫在最后

本文介紹了TiDB在轉轉公司的發展歷程，從調研測試到投產使用，從命令行運維到自動化平臺管理，將業務日常需求基本實現了工單化，DBA日常管理維護的操作基本都實現了平臺化。

一切自動化的前提是先實現規范化。

我們一步一步走過來，遇到了很多問題，也解決了很多問題，但各自環境不同，需求也不同，還可能碰上其他未知的問題，本文所有內容僅供參考。

關于作者

莫善，轉轉DBA。負責TiDB，MongoDB，MySQL運維及轉轉數據庫平臺開發。