雷神 Thor —— TiDB 自動化運維平臺

做者：瞿鍇，同程藝龍資深 DBA

背景介紹

隨着互聯網的飛速發展，業務量可能在短短的時間內爆發式地增加，對應的數據量可能快速地從幾百 GB 漲到幾百個 TB，傳統的單機數據庫提供的服務，在系統的可擴展性、性價比方面已經再也不適用。爲了應對大數據量下業務服務訪問的性能問題，MySQL 數據庫經常使用的分庫、分表方案會隨着 MySQL Sharding（分片）的增多，業務訪問數據庫邏輯會愈來愈複雜。並且對於某些有多維度查詢需求的表，須要引入額外的存儲或犧牲性能來知足查詢需求，這樣會使業務邏輯愈來愈重，不利於產品的快速迭代。

TiDB 的架構

TiDB 做爲 PingCAP 旗下開源的分佈式數據庫產品，具備多副本強一致性的同時可以根據業務需求很是方便的進行彈性伸縮，而且擴縮容期間對上層業務無感知。TiDB 包括三大核心組件：TiDB/TiKV/PD。

TiDB Server：主要負責 SQL 的解析器和優化器，它至關於計算執行層，同時也負責客戶端接入和交互。

TiKV Server：是一套分佈式的 Key-Value 存儲引擎，它承擔整個數據庫的存儲層，數據的水平擴展和多副本高可用特性都是在這一層實現。

PD Server：至關於分佈式數據庫的大腦，一方面負責收集和維護數據在各個 TiKV 節點的分佈狀況，另外一方面 PD 承擔調度器的角色，根據數據分佈情況以及各個存儲節點的負載來採起合適的調度策略，維持整個系統的平衡與穩定。

上面的這三個組件，每一個角色都是一個多節點組成的集羣，因此最終 TiDB 的架構看起來是這樣的。

因而可知，分佈式系統自己的複雜性致使手工部署和運維的成本是比較高的，而且容易出錯。傳統的自動化部署運維工具如 Puppet / Chef / SaltStack / Ansible 等，因爲缺少狀態管理，在節點出現問題時不能及時自動完成故障轉移，須要運維人員人工干預。有些則須要寫大量的 DSL 甚至與 Shell 腳本一塊兒混合使用，可移植性較差，維護成本比較高。

針對 TiDB 這種複雜的分佈式數據庫，咱們考慮經過對 TiDB 容器化管理，實現如下幾個目的：

1、屏蔽底層物理資源

2、提高資源利用率（CPU、內存）

3、提高運維效率

4、精細化管理

所以結合上述須要，咱們開發了雷神系統來統一管理和維護 TiDB，其總體架構以下：

從架構圖中能夠看出此方案是 TiDB 的私有云架構。最下層是容器雲，中間一層是開發的容器編排工具，最上面一層針對 TiDB 特性和實際使用中遇到的問題點，進行了針對性開發從而實現了 TiDB 集羣實例的統一化管理。下面將逐個介紹各個模塊的功能。

容器調度

目前主流的的容器編排系統 Kuberbetes 曾是咱們容器調度的首選解決方案。但 TiDB 做爲數據庫服務須要將數據庫存儲到本地磁盤，而 Kuberbetes 對 Local Storage 不支持（目前新的版本已經開始支持）。針對 TiDB 的特性和業務需求，咱們決定本身實現一套容器編排系統，具體解決如下問題：

• 支持 LocalStorage，解決數據存儲問題
• 基於 cpuset-cpus 實現 CPU 資源的隨機均衡分配
• 定製化，支持 label，實現特定服務運行在特定宿主機上；宿主機資源限制
• 容器的主動發現和通知，以便將以前未管理的宿主機接入統一管理
• 容器的全生命週期的管理
• 容器異常的修復和通知

雷神 Thor 採用了模塊化設計，分爲控制模塊和代理模塊，其總體架構以下：

說明：

• 控制模塊包含了 Allocator，Label，Discover，Manage，Customize。Allocator 主要負責宿主機資源的分配；Label 主要用於標籤訂製；Customize 主要負責定製化需求； Discover 主要負責容器的發現和異常檢測；Manage 主要負責總體的調度和分發。
• 代理模塊主要負責資源檢查和信息收集、接受控制端的命令。

集羣管理

集羣管理是整套系統的核心模塊之一，包含了 TiDB 集羣的平常維護操做，實現了 TiDB 初始化、平滑升級、彈性容量管理、監控的整合、集羣的維護、節點的維護等功能。雖然 PingCAP 提供了基於 Ansible 的自動部署方案，可是依然須要填寫大量的內容和檢查相關機器設定來完成部署。經過此係統只須要將需求按照如何格式提交，便可完成整套集羣的部署，部署時間從以前 2 個小時，縮減爲 2 分鐘左右。

數據庫管理

數據庫管理是平常運維很核心的一塊，此模塊經過任務完成統計信息更新、過載保護、慢查詢分析和 SQL 預警。

1. 統計信息更新

TiDB 雖然會自動更新統計信息，但須要達到固定的變動百分比，因 TiDB 是做爲分片庫的合併庫，數據量高達幾十億，若依賴自身的統計信息維護，將出現因統計信息不許確而觸發的慢查詢，故針對此種狀況，設計和開發統計信息自動更新，除常規設定外，還可設定例外，避免因統計信息更新時影響業務的正常使用。

2. 過載保護

經過對 SQL 的執行時間和內存的使用狀況分析，針對不一樣的集羣能夠定製不一樣的過載保護策略，也可使用統一的過載保護策略；當觸發策略時，會將相關信息經過微信的方式通知相關人員。

3. 慢查詢分析和 SQL 預警

經過 ELK 構建慢查詢分析系統，經過 mysql-sniffer、flume、kafka、spark、hadoop 構建 SQL 預警，經過對趨勢的分析和預判，爲後續自動化容量管理作數據的積累。

數據同步

咱們嘗試將 TiDB 做爲全部數據的集合庫提供複雜查詢，分片集羣則提供簡單查詢，同時因爲 TiDB 高度兼容 MySQL 的鏈接協議爲知足複雜的業務查詢需求，咱們基於 PingCAP 的數據同步工具 Syncer 進行了代碼重構，開發了 hamal 同步工具，能夠自定義庫名和表名，同時新增了同步狀態監控，如 TPS、延遲等，若是出現異常，會經過微信告警。從 MySQL 將數據實時同步到 TiDB 來確保數據的一致。該實時同步查詢系統架構以下所示：

Hamal 是假裝成 mysql 從，從 mysql 主上經過主從複製協議來解析成對應的 sql 語句，並通過過濾、改寫等步驟，將最終語句在目標庫執行的工具。Hamal 主要包含如下特性：

• position 以及 gtid 模式支持
• 自動切換主從支持（須要提早配置好主從服務列表）
• 多目標庫支持（多 tidb-server）
• binlog 心跳支持
• 庫、表級別過濾，重寫支持（用於分片合庫）
• 庫表級別額外索引支持
• 拆解字段支持（額外輸出選擇某幾個字段的小表）
• 字段過濾支持
• 智能更新表結構
• 多線程合併小事務後執行，多種分發策略
• 純文本執行模式支持

Hamal 的內部實現以下：

從架構圖中能夠看出，經過設定不一樣的 generators，hamal 支持同步到不一樣目的庫或者其餘存儲方式。

監控和告警中心

監控對於系統的重要性不言而喻。可否有效的告警直接影響着監控的質量，所以監控的核心是監控數據的採集和有效的告警。監控數據主要有三種系統自己的運行狀態，例如 CPU、內存、磁盤、網絡的使用狀況；各類應用的運行情況，例如數據庫、容器等，處理網絡上發送過來的數據。經過監控項設定和監控例外，能夠靈活的定製監控信息的收集。合理、靈活的監控規則能夠幫助更快、更精確的定位異常，經過告警策略和告警例外知足不一樣的告警需求。監控和告警中心的架構圖以下：

其中，監控數據的採集一部分依賴於現有監控系統中的數據，如 zabbix 之類；一部分經過 TiDB 的 API 獲取，一部分是開源的收集器，所以致使原始數據存儲在不一樣類型的數據庫，經過開發的同步工具，將上述數據同步獨立部署的 TiDB 集羣，以便後續的數據分析。可視化的實現主要基於 grafana 來完成。告警模塊是基於實際的需求，進行開發和實現的，未採用現有的一些開源方案。

總結

在對 TiDB 的使用過程當中，咱們按照 1 庫 1 集羣的方式進行服務部署，這種部署方式能夠有效避免不一樣庫的壓力不均致使相互影響的問題，同時性能監控精準到庫級別，而使用了雷神系統後，可以有效的在單臺服務器上對各類服務資源進行快速部署，提高資源利用率的同時避免資源爭用帶來的問題。

系統上線一年以來，已完成公司全部 TiDB 集羣從物理機部署到容器化的平穩遷移；管理了數百臺機器和數十套 TiDB Cluster，接入應用數百個，承載着幾十 T 的數據量，峯值 TPS 數十萬；上線前部署一個 TiDB 集羣須要花費將近 2 個小時，雷神系統上線後只須要 2 分鐘便可部署完成。有效的提高了 DBA 的運維效率和整個 TiDB 服務的可用性。

將來咱們將繼續深刻，從審計和 SQL 分析方面着手，爲業務提供更多的效率提高和穩定性保障。

原文連接：雷神Thor—TIDB自動化運維平臺