作者：瞿鍇，同程藝龍資深 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 容器化管理，實現以下幾個目的：
一、遮蔽底層物理資源
二、提升資源利用率（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 預警。
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自動化運維平臺
