轉轉技術
轉轉研發中心及業界小夥伴們的技術學習交流平臺，定期分享一線的實戰經驗及業界前沿的技術話題。 各種乾貨實踐，歡迎交流分享，如有問題可隨時聯絡 waterystone ~
莫善
轉轉 DBA。 負責 TiDB，MongoDB，MySQL 運維及轉轉資料庫平臺開發。
轉轉是 PingCAP 最早的一批使用者之一，見證了 TiDB 的發展，自身也沉澱了不少經驗。
從 1.0 GA 開始測試，到 2.0 GA 正式投產，然後升級到了 2.1，後來又升級到 4.0.13，最後建設自動化平臺。其實轉轉 DBA 團隊初建以來就開始投入一定的資源進行平臺建設，一步一步實現自動化運維，希望一切需求都能實現工單化、一切操作都能實現平臺化，進而降低人力成本。
本文將分享轉轉 DBA 團隊實現 TiDB 自動化的歷程。從遇到問題開始，到解決問題，以及平臺做成什麼樣，也是對過去工作的總結和梳理。
運維痛點
- 轉轉現有叢集 30 多套，早期都是 2.1.[5,7,8,17] 版本，近 500 個 TiKV 節點，總共差不多一百臺機器供 TiKV 使用，叢集新建、擴容、遷移都需要人工找機器。也因為缺少一個上帝的視角去管理叢集，沒法做到資源的合理分配，導致日常工作中有很大一部分時間都是在做遷移，都是重複工作，效率很低。
- 2.1 版本的運維工作都是基於 Ansible 進行。如擴容、下線、啟停、修改配置等日常操作，有時候會碰到 Ansible 執行超時的情況。批次操作叢集時，根本不知道到哪個節點了，這情況經常能遇到，在 reload 叢集配置檔案的時候遇到的機率就非常大，要多崩潰有多崩潰。
- 2.1 版本的 TiDB 自身有很多問題，執行計劃失效、讀寫熱點問題（不能快速定位問題）、TiDB 大查詢 OOM、樂觀事務、監控不完善、以及已知/未知的問題，就連叢集狀態都無法快速獲取，當然備份也很痛苦，這對運維人員的工作加大了難度，也提升了人力成本。
- 4.0 使用悲觀事務需要滿足一定的要求，具體請參考官方檔案。
- 機器資源使用不平衡，存在部分機器記憶體剩餘較多但是磁碟不足，還有部分機器記憶體不足，但是磁碟剩餘很多。導致的結果是老闆覺得機器投入已經很大，但是 DBA 實際使用中發現機器還是不夠用。
- 告警噪音比較多，存在重複告警，互相沖刷問題，嚴重浪費告警資源，對排查問題也帶來很不友好的體驗。
解決痛點
後設資料管理
將所有節點資訊儲存到表裡，定期採集節點狀態及資源使用情況。
過去都是依靠 Ansible 的配置檔案進行管理，管理視角基本是停留在叢集都有哪些節點，連一臺機器都有哪些例項都不清楚，更別談資源管理了。
現在將所有元件儲存到一個表中，定期採集元件服務狀態，記憶體磁碟佔有量等資訊。這樣就有了一個全域性的視角進行管理，也很方便的查閱叢集狀態。
後續基於這份後設資料進行專案成本核算。
還有一個收益就是，元件資訊的採集，可以很好的控制單個 TiKV 的容量，不會再出現單個叢集容量一直增長，然後觸發機器的磁碟告警 DBA 才感知到。有了這個採集的資料後，可以設定一個 TiKV 容量上限，比如 500GB，達到這個閾值就傳送告警給 DBA 準備擴容。這樣能很好的避免因機器磁碟告警而接收大量告警資訊（單機多例項），也能提供一個很好的緩衝時間讓 DBA 來處理。
總結起來就是，能很好的將機器/叢集/元件管理起來，能合理有效的進行資源排程，也為實現自動化提供了基礎資料。
機器資源管理
將所有機器資訊儲存到表裡，定期採集硬體資源使用情況。這麼做能獲得如下兩點收益：
- 第一是對已有環境進行 rebalance。有了後設資料資訊，就可以很好的展開 rebalance 工作了。最終收益很明顯，既提高了資源利用率，還降低了 15% 的機器資源。
- 第二是能合理有效的進行資源排程，為實現自動化提供了基礎資料。（同後設資料管理）
後設資料管理和機器資源管理，這兩部分工作既降低了成本也提升了工作效率同時也是監控的兜底策略，會基於這兩個資料表進行監控：
（1）程式是否正常。
（2）機器是否正常。
全面升級
將所有 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%，解決了抽數帶來的影響，升級以後暫時沒有收到因抽數導致影響到業務的反饋，在升級前幾乎每兩個月都會有至少一次因為抽數導致業務受影響。
告警改造
支援簡訊、語音告警，並實現告警收斂、抑制，告警升級。大大降低告警條數（條數至少能降低 60%），節約告警資源。
收斂和抑制目的是降噪。
告警升級主要是為了降低告警成本，升級分如下幾個維度：
- 第一：介質升級。郵件 --> 企業微信 --> 簡訊 --> 電話（同一個告警項傳送超過 3 次就向上升級一個介質，具體可以根據需求定義）。
- 第二：接收人升級。一級 --> 二級 --> leader。
- 第三：按照時間升級。工作時間透過郵件/企業微信傳送告警，工作時間之外透過簡訊/電話傳送告警。
詳情請看這篇文章： 基於 Alertmanager 告警系統的改造
實現自動化
分散式叢集有很多優點，但是對 DBA 來說也增加了運維複雜度，有些叢集幾十上百個節點，全靠人工去管理運維無疑是很痛苦。
轉轉現在基本完成了自動化，收益也很明顯，這部分主要是想分享一下注意事項或者遇到的問題，僅供參考。
需求工單化
這部分主要是在平臺透過工單的方式實現了業務的日常的需求，降低了溝通成本，實現了業務需求審計，還能減少 DBA 的工作量。
目前支援如下工單型別。
工單型別
叢集部署工單
在 4.0 版本中，部署一個新叢集比較麻煩的是拓撲檔案的生成，倒不是有多複雜，而是因為一個叢集的元件太多，每種元件對硬體的要求又有些區別。
比如 Grafana，Alertmanager 這種不需要 IO，PD，TiKV，TiFlash 對 IO 又要求比較高，另外還需要根據服務的重要程度進行合理的規劃，重要的服務單獨部署或者儘可能的減少節點數，需要考慮的點參考維度有點多。
以上只是針對部署叢集需要關注的點，還有一些額外的考慮點，或者說操作細節。總結起來如下：
- 為各個角色選擇合適的機器，完成拓撲檔案，然後部署叢集。
- 初始化叢集，建立業務使用者，業務域名。
- 配置 Grafana，Prometheus，Alertmanager，Dashboard 等平臺，建立必要的使用者，以及 Grafana，Dashboard 許可權控制，以及功能驗證測試等。
- 叢集資訊入庫，將必要的資訊同步到業務側。
所以實現工單化，不僅輕鬆解決資源排程問題，提升機器資源利用率，還可以大大提升效率，避免操作出錯或者遺漏。尤其是功能驗證，萬一業務上線以後才發現問題，影響面就比較大了。
新建叢集
透過 sic 判斷叢集重要等級，預估 QPS，TPS 作為輔助參考項，最終根據評分為其分配合理的機器進行叢集部署。
資料恢復工單
這類需求在工作中倒不是很多，但是一旦遇到就會比較緊急。實現這類工單後，不僅可以降低溝通成本，降低故障的影響時間，也能降低人力成本。
目前支援兩個維度的資料恢復。
- 一種是基於快照，如果恢復需求的時間點在 GC 時間之內的，就直接透過快照進行資料恢復，所以這類需求恢復速度較快。
- 一種是基於備份檔案，如果恢復的時間點位不在 GC 時間之內的，就只能選擇最接近該時間點的備份檔案來恢復了。
目前這兩類維度都支援整庫（一個工單僅限單庫），單表或者多表。基於快照的還支援帶特定條件，基於備份檔案的不支援帶條件。所以相對來說基於快照的複雜一些，特別是多表需要恢復到某一個時間點，且是帶條件恢復（單表部分資料）。
比如一個訂單，涉及多個表，需要將多個表某些訂單號的資料恢復到特定時間點。
由此可見，基於快照的恢復是比較靈活的，使用者可以選單庫，或者單表，還可以選擇多表，由於我們並不知道使用者需要恢復幾張表，所以帶查詢條件的邏輯應該是動態的，即當使用者選擇了某個表，就會彈出改表的查詢條件輸入框，有幾個表就有幾個輸入框，根據提示輸入到對應的表即可，如下圖所示。
資料恢復
TiCDC 工單
轉轉公司有一種特殊業務需求，需要將業務的資料抽取到大資料平臺，主要是給業務提供經營資料分析、使用者行為和畫像資產沉澱以及一些趨勢預測。
如果是 MySQL 直接做一個專門提供資料抽取的從庫就行了，但是 TiDB 不行，雖然可以暴露一個 TiDB 節點給大資料進行資料抽取，但是本質上還是對同一組 TiKV 進行操作，所以抽數操作很容易引起業務的抖動。
現在我們提供了兩種方案給業務進行選擇，優先可以選擇 TiCDC，如果 TiCDC 不能滿足的情況下可以使用 TiFlash。
TiCDC
對於已經存在 cdc 任務，只需更新配置即可，另外需要注意下游如果是 kafka 的話，資料包的大小，要求跟 kafka 的最大值配置一致，否則可能會報錯，尤其是 TiDB 端擴大表結構的場景。
對我們來說，TiCDC 需求真的太需要實現工單化了。那些需要抽數的業務，幾乎新增一個表就需要更新 TiCDC 的任務，之前都是郵件溝通，如今實現工單後，對業務，對大資料團隊，又或者是 DBA 都是十分方便的，降低了三方的溝通成本，提升工作效率。
TiFlash 工單
需求同 TiCDC 工單。
TiFlash
從成本上考慮，TiCDC 不需要額外的儲存空間，所以更優，也更受歡迎。但是存在一定的風險，比如 TiCDC 到下游的同步鏈路出現問題（上游 TiDB 業務進行調整可能會導致同步中斷），那麼下游就會無法獲取增量資料。
TiFlash 則不會有這個問題，但是需要犧牲一定的儲存空間，業務成本會有所提升，需要業務自己去權衡。
操作平臺化
這部分主要是在平臺透過頁面操作實現了日常的管理，降低了運維成本，實現了操作審計，還能避免一定的人為操作失誤。
節點管理
這部分涉及節點的啟動、關閉、重啟、下線、維護等。節點啟停、重啟流程比較簡單，這裡不做過多介紹。
節點管理
只有當節點處於關閉狀態才會有啟動選項。另外需要注意的是，重啟操作已經改成 reload，這樣對業務的影響相對小一些。前提是要評估好 restart 是否等價於 reload（沒有變更配置基本不會有什麼問題）。
下線和維護操作需要注意如下幾個事項：
節點管理
- 下線的目標節點是否是該角色的最後一個節點，或者是否滿足 raft 協議的最低要求，如果是則不能直接下線，需要人工介入。
- 維護操作主要是需要聯動一下告警靜默，因為維護操作本身是計劃內操作，對於不必要的告警可以提前規避掉。
對於 PD，TiKV 等元件對數量是有要求的，PD，TiKV 最少要求兩個，所以當叢集只剩兩個節點的時候是不允許下線的，需要 DBA 介入操作，當然還有 DM-worker，TiFlash 等元件也是有最低數量要求，需要根據實際情況進行判斷。
擴容管理
擴容分兩種情況，一種是主動擴容，一種是自動擴容。這個小結是介紹主動擴容，至於自動擴容後文會介紹。
擴容功能比較靈活，支援多角色同時擴容，節點個數可配置，目標地址也可配置，如下圖所示：
擴容
未指定地址的話就由系統預設分配合理的目標地址。
下線管理
下線要求是序列操作，即一個叢集在同一個時間只能有一個節點被下線，等待下線後才能下線第二個節點。另外，如果是儲存節點（TiKV，TiFlash，Pump），需要等待資料遷移完畢後，執行完叢集調整（prune）操作才算下線完成。
下線
需要考慮一下異常節點的下線，即機器當機不可恢復的情況，所以我們增加了一個強制下線的選項來處理此類異常場景。
告警管理
告警跟運維工作息息相關，一個好的告警管理平臺不僅能提升運維的效率，還能提升工作舒適度及生活質量。
我們的告警管理平臺現在功能比較簡單，後續會慢慢豐富。
- 支援預先配置告警靜默，比如將對某個叢集進行維護，可以先將該叢集的告警進行靜默。
告警管理
靜默時間最長不允許超過 24 小時，預設是 2 小時，這樣可以避免因遺忘導致該告警項被長時間靜默。
- 支援針對已經告警的項進行靜默。這部分邏輯是將所有告警項展示出來，供使用者選擇。
- 如下是正在告警列表展示頁
告警管理-告警列表
支援一鍵靜默，即：正在告警的項全部靜默。
如下是靜默規則列表展示頁，正在執行的靜默規則支援刪除及禁用，禁用狀態的允許重新啟用。
告警管理-靜默規則列表
慢查詢告警
這個功能是統計單位時間內慢查詢條目增長量，當達到告警閾值就會觸發告警，使用者可以設定統計的時間範圍，以及慢查詢閾值，還有告警閾值。
慢查詢告警-新增規則
叢集的慢查詢閾值大於使用者定義的規則的慢查詢最小閾值，會將叢集的慢查詢閾值設定為該閾值。如叢集慢查詢閾值是 300ms，使用者定義告警閾值是 200ms，這時候會將叢集的慢查詢閾值設定為 200ms。
如下是規則列表展示頁，支援規則禁用及刪除，禁用後可以重新啟用。
慢查詢告警-規則展示頁
其他輔助功能
程式監控
程式監控
因 線上機器 基本都是單機多例項，有時 候會出現因為某個例項而影響了整個機器的效能，在沒有程式級別的監控下，對我們排查定位問題十分痛苦，為解決這一個痛點，我們開發了程式維度的監控系統，這樣可以很好的協助運維人員排查定位機器資源跑滿等問題。
程式級別的資源監控，包括但是不限於 CPU, 記憶體, 磁碟 IO, 網路流量，功能還在繼續豐富。具體實現可以參考這個文章： Linux 環境下針對程式維度的監控實現
程式 監控
會記錄每個程式的資源使用情況，其中網路資料是做了限制，只有達到閾值才會採集，所以會出現空白頁情況。另外網路傳輸資料會記錄源端到目的端資訊。
趨勢監控
隨著時間的推移，業務資料也在不斷的增長。那麼問題來了，這個增長是否符合預期？按照這個增量，磁碟空間能支援多長時間？為瞭解決這兩個問題，我們採取了趨勢分析的方案，提前監控，分析增長趨勢，對於增長異常的叢集會和業務進行溝通確認，對於磁碟空間臨近告警線會提前遷移。
程式監控
- 增量告警，當資料目錄在三日內連續單日增長超過 20GB，每個月增量超過 200GB 就會傳送告警給業務，請業務進行確認。
- 全量告警，當資料目錄達到告警閾值就給 DBA 傳送告警。
自動運維
- 自適應遷移
當機器準備達到記憶體告警閾值，磁碟告警閾值，就自動遷移。
- 自適應擴容
當單個 TiKV 容量達到 800GB 就自動進行擴容。
不管是自適應遷移還是擴容，都可以減少 DBA 的工作量，也能在一定程度上減少告警量。對於擴容，既控制了單個 TiKV 的大小，對於系統效能也會有一定的提升。
單節點 TiKV 太大，不利於管理。在節點下線的場景下會拉長資料遷移的時間，在節點離線的場景下，會拉長生成新副本的時間。
寫在最後
本文介紹了 TiDB 在轉轉公司的發展歷程，從調研測試到投產使用，從命令列運維到自動化平臺管理，將業務日常需求基本實現了工單化，DBA 日常管理維護的操作基本都實現了平臺化。
一切自動化的前提是先實現規範化。
我們一步一步走過來，遇到了很多問題，也解決了很多問題，但各自環境不同，需求也不同，還可能碰上其他未知的問題，本文所有內容僅供參考。