TiDB在轉轉公司的發展歷程

• 1 前言

• 2 運維痛點

• 3 解決痛點

• 3.1 後設資料管理

• 3.2 機器資源管理

• 3.3 全面升級

• 3.4 告警改造

• 4 實現自動化

• 4.1 需求工單化

• 4.2 操作平臺化

• 4.3 其他輔助功能

• 5 寫在最後

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進行區別。可以避免管理員賬戶洩露的問題，但是帶來新的問題就是賬戶管理變得複雜了。

全部完成升級後。整體效能提升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。

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

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

（4）TiFlash工單

需求同TiCDC工單。

從成本上考慮，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日常管理維護的操作基本都實現了平臺化。

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

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