1 前言

轉(zhuǎn)轉(zhuǎn)是PingCAP最早的一批用戶之一，見證了TiDB的發(fā)展，自身也沉淀了不少經(jīng)驗。

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

其實轉(zhuǎn)轉(zhuǎn)DBA團(tuán)隊初建以來就開始投入一定的資源進(jìn)行平臺建設(shè)，一步一步實現(xiàn)自動化運(yùn)維，希望一切需求都能實現(xiàn)工單化、一切操作都能實現(xiàn)平臺化，進(jìn)而降低人力成本。

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

2 運(yùn)維痛點

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

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

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

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

（4）機(jī)器資源使用不平衡，存在部分機(jī)器內(nèi)存剩余較多但是磁盤不足，還有部分機(jī)器內(nèi)存不足，但是磁盤剩余很多。導(dǎo)致的結(jié)果是老板覺得機(jī)器投入已經(jīng)很大，但是DBA實際使用中發(fā)現(xiàn)機(jī)器還是不夠用。

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

3 解決痛點

3.1 元數(shù)據(jù)管理

將所有節(jié)點信息保存到表里，定期采集節(jié)點狀態(tài)及資源使用情況。

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

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

后續(xù)基于這份元數(shù)據(jù)進(jìn)行項目成本核算。

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

總結(jié)起來就是，能很好的將機(jī)器/集群/組件管理起來，能合理有效的進(jìn)行資源調(diào)度，也為實現(xiàn)自動化提供了基礎(chǔ)數(shù)據(jù)。

3.2 機(jī)器資源管理

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

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

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

3.3 全面升級

將所有2.1集群升到4.0.13。

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

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

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

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

3.4 告警改造

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

收斂和抑制目的是降噪。

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

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

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

4 實現(xiàn)自動化

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

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

4.1 需求工單化

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

目前支持如下工單類型。

工單類型

（1）集群部署工單

在4.0版本中，部署一個新集群比較麻煩的是拓?fù)湮募纳?，倒不是有多?fù)雜，而是因為一個集群的組件太多，每種組件對硬件的要求又有些區(qū)別。

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

以上只是針對部署集群需要關(guān)注的點，還有一些額外的考慮點，或者說操作細(xì)節(jié)?？偨Y(jié)起來如下：

• 為各個角色選擇合適的機(jī)器，完成拓?fù)湮募?，然后部署集群?/li>
• 初始化集群，創(chuàng)建業(yè)務(wù)用戶，業(yè)務(wù)域名。
• 配置Grafana，Prometheus，Alertmanager，Dashboard等平臺，創(chuàng)建必要的用戶，以及Grafana，Dashboard權(quán)限控制，以及功能驗證測試等。
• 集群信息入庫，將必要的信息同步到業(yè)務(wù)側(cè)。

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

新建集群

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

（2）數(shù)據(jù)恢復(fù)工單

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

目前支持兩個維度的數(shù)據(jù)恢復(fù)。

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

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

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

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

數(shù)據(jù)恢復(fù)

（3）TiCDC工單

轉(zhuǎn)轉(zhuǎn)公司有一種特殊業(yè)務(wù)需求，需要將業(yè)務(wù)的數(shù)據(jù)抽取到大數(shù)據(jù)平臺，主要是給業(yè)務(wù)提供經(jīng)營數(shù)據(jù)分析、用戶行為和畫像資產(chǎn)沉淀以及一些趨勢預(yù)測。

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

現(xiàn)在我們提供了兩種方案給業(yè)務(wù)進(jìn)行選擇，優(yōu)先可以選擇TiCDC，如果TiCDC不能滿足的情況下可以使用TiFlash。

ticdc

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

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

（4）TiFlash工單

需求同TiCDC工單。

tiflash

從成本上考慮，TiCDC不需要額外的存儲空間，所以更優(yōu)，也更受歡迎。但是存在一定的風(fēng)險，比如TiCDC到下游的同步鏈路出現(xiàn)問題（上游TiDB業(yè)務(wù)進(jìn)行調(diào)整可能會導(dǎo)致同步中斷），那么下游就會無法獲取增量數(shù)據(jù)。

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

4.2 操作平臺化

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

（1）節(jié)點管理

這部分涉及節(jié)點的啟動、關(guān)閉、重啟、下線、維護(hù)等。節(jié)點啟停、重啟流程比較簡單，這里不做過多介紹。

節(jié)點管理

只有當(dāng)節(jié)點處于關(guān)閉狀態(tài)才會有啟動選項。另外需要注意的是，重啟操作已經(jīng)改成reload，這樣對業(yè)務(wù)的影響相對小一些。前提是要評估好restart是否等價于reload（沒有變更配置基本不會有什么問題）。

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

節(jié)點管理

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

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

（2）擴(kuò)容管理

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

擴(kuò)容功能比較靈活，支持多角色同時擴(kuò)容，節(jié)點個數(shù)可配置，目標(biāo)地址也可配置，如下圖所示：

擴(kuò)容

未指定地址的話就由系統(tǒng)默認(rèn)分配合理的目標(biāo)地址。

（3）下線管理

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

下線

需要考慮一下異常節(jié)點的下線，即機(jī)器宕機(jī)不可恢復(fù)的情況，所以我們增加了一個強(qiáng)制下線的選項來處理此類異常場景。

（4）告警管理

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

我們的告警管理平臺現(xiàn)在功能比較簡單，后續(xù)會慢慢豐富。

• 支持預(yù)先配置告警靜默，比如將對某個集群進(jìn)行維護(hù)，可以先將該集群的告警進(jìn)行靜默。

告警管理

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

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

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

告警管理-告警列表

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

如下是靜默規(guī)則列表展示頁，正在運(yùn)行的靜默規(guī)則支持刪除及禁用，禁用狀態(tài)的允許重新啟用。

告警管理-靜默規(guī)則列表

（5）慢查詢告警

這個功能是統(tǒng)計單位時間內(nèi)慢查詢條目增長量，當(dāng)達(dá)到告警閾值就會觸發(fā)告警，用戶可以設(shè)置統(tǒng)計的時間范圍，以及慢查詢閾值，還有告警閾值。

慢查詢告警-添加規(guī)則

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

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

慢查詢告警-規(guī)則展示頁

4.3 其他輔助功能

（1）進(jìn)程監(jiān)控

進(jìn)程監(jiān)控

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

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

進(jìn)程監(jiān)控

會記錄每個進(jìn)程的資源使用情況，其中網(wǎng)絡(luò)數(shù)據(jù)是做了限制，只有達(dá)到閾值才會采集，所以會出現(xiàn)空白頁情況。另外網(wǎng)絡(luò)傳輸數(shù)據(jù)會記錄源端到目的端信息。

（2）趨勢監(jiān)控

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

進(jìn)程監(jiān)控

• 增量告警，當(dāng)數(shù)據(jù)目錄在三日內(nèi)連續(xù)單日增長超過20GB，每個月增量超過200GB就會發(fā)送告警給業(yè)務(wù)，請業(yè)務(wù)進(jìn)行確認(rèn)。
• 全量告警，當(dāng)數(shù)據(jù)目錄達(dá)到告警閾值就給DBA發(fā)送告警。

（3）自動運(yùn)維

• 自適應(yīng)遷移

當(dāng)機(jī)器準(zhǔn)備達(dá)到內(nèi)存告警閾值，磁盤告警閾值，就自動遷移。

• 自適應(yīng)擴(kuò)容

當(dāng)單個TiKV容量達(dá)到800GB就自動進(jìn)行擴(kuò)容。

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

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

5 寫在最后

本文介紹了TiDB在轉(zhuǎn)轉(zhuǎn)公司的發(fā)展歷程，從調(diào)研測試到投產(chǎn)使用，從命令行運(yùn)維到自動化平臺管理，將業(yè)務(wù)日常需求基本實現(xiàn)了工單化，DBA日常管理維護(hù)的操作基本都實現(xiàn)了平臺化。

一切自動化的前提是先實現(xiàn)規(guī)范化。

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

關(guān)于作者

莫善，轉(zhuǎn)轉(zhuǎn)DBA。負(fù)責(zé)TiDB，MongoDB，MySQL運(yùn)維及轉(zhuǎn)轉(zhuǎn)數(shù)據(jù)庫平臺開發(fā)。