摘要：相當于分布式數據庫的大腦，一方面負責收集和維護數據在各個節點的分布情況，另一方面承擔調度器的角色，根據數據分布狀況以及各個存儲節點的負載來采取合適的調度策略，維持整個系統的平衡與穩定。原文鏈接雷神自動化運維平臺

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

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

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 容器化管理，實現以下幾個目的：

一、屏蔽底層物理資源

二、提升資源利用率（CPU、內存）

三、提升運維效率

四、精細化管理

因此結合上述需要，我們開發了雷神系統來統一管理和維護 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 預警。

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

通過對 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自動化運維平臺