建站
咨詢
售后
建站咨詢
新聞中心
1 前言
轉(zhuǎn)轉(zhuǎn)是PingCAP最早的一批用戶之一，見證了TiDB的發(fā)展，自身也沉淀了不少經(jīng)驗(yàn)。
我們提供的服務(wù)有：成都網(wǎng)站建設(shè)、成都網(wǎng)站設(shè)計(jì)、微信公眾號(hào)開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認(rèn)證、南京ssl等。為近千家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務(wù)，是有科學(xué)管理、有技術(shù)的南京網(wǎng)站制作公司
從1.0 GA開始測(cè)試，到2.0 GA正式投產(chǎn)，然后升級(jí)到了2.1，后來又升級(jí)到4.0.13，最后建設(shè)自動(dòng)化平臺(tái)。
其實(shí)轉(zhuǎn)轉(zhuǎn)DBA團(tuán)隊(duì)初建以來就開始投入一定的資源進(jìn)行平臺(tái)建設(shè)，一步一步實(shí)現(xiàn)自動(dòng)化運(yùn)維，希望一切需求都能實(shí)現(xiàn)工單化、一切操作都能實(shí)現(xiàn)平臺(tái)化，進(jìn)而降低人力成本。
本文就想來分享一下TiDB實(shí)現(xiàn)自動(dòng)化的歷程。從遇到問題開始，到解決問題，以及平臺(tái)做成什么樣，也是對(duì)過去的工作做一個(gè)總結(jié)和梳理。
2 運(yùn)維痛點(diǎn)
（1）轉(zhuǎn)轉(zhuǎn)現(xiàn)有集群30多套，早期都是2.1.[5,7,8,17]版本，近500個(gè)TiKV節(jié)點(diǎn)，總共差不多一百臺(tái)機(jī)器供TiKV使用，集群新建、擴(kuò)容、遷移都需要人工找機(jī)器。也因?yàn)槿鄙僖粋€(gè)上帝的視角去管理集群，沒法做到資源的合理分配，導(dǎo)致日常工作中有很大一部分時(shí)間都是在做遷移，都是重復(fù)工作，效率很低。
（2）2.1版本的運(yùn)維工作都是基于Ansible進(jìn)行。如擴(kuò)容、下線、啟停、修改配置等日常操作，有時(shí)候會(huì)碰到Ansible執(zhí)行超時(shí)的情況。批量操作集群時(shí)，根本不知道到哪個(gè)節(jié)點(diǎn)了，這情況經(jīng)常能遇到，在reload集群配置文件的時(shí)候遇到的概率就非常大，要多崩潰有多崩潰。
（3）2.1版本的TiDB自身有很多問題，執(zhí)行計(jì)劃失效、讀寫熱點(diǎn)問題（不能快速定位問題）、TiDB大查詢OOM、樂觀事務(wù)、監(jiān)控不完善、以及已知/未知的問題，就連集群狀態(tài)都無法快速獲取，當(dāng)然備份也很痛苦，這對(duì)運(yùn)維人員的工作加大了難度，也提升了人力成本。
4.0 使用悲觀事務(wù)需要滿足一定的要求，具體請(qǐng)參考官方文檔。
（4）機(jī)器資源使用不平衡，存在部分機(jī)器內(nèi)存剩余較多但是磁盤不足，還有部分機(jī)器內(nèi)存不足，但是磁盤剩余很多。導(dǎo)致的結(jié)果是老板覺得機(jī)器投入已經(jīng)很大，但是DBA實(shí)際使用中發(fā)現(xiàn)機(jī)器還是不夠用。
（5）告警噪音比較多，存在重復(fù)告警，互相沖刷問題，嚴(yán)重浪費(fèi)告警資源，對(duì)排查問題也帶來很不友好的體驗(yàn)。
3 解決痛點(diǎn)
3.1 元數(shù)據(jù)管理
將所有節(jié)點(diǎn)信息保存到表里，定期采集節(jié)點(diǎn)狀態(tài)及資源使用情況。
過去都是依靠Ansible的配置文件進(jìn)行管理，管理視角基本是停留在集群都有哪些節(jié)點(diǎn)，連一臺(tái)機(jī)器都有哪些實(shí)例都不清楚，更別談資源管理了。
現(xiàn)在將所有組件保存到一個(gè)表中，定期采集組件服務(wù)狀態(tài)，內(nèi)存磁盤占有量等信息。這樣就有了一個(gè)全局的視角進(jìn)行管理，也很方便的查閱集群狀態(tài)。
后續(xù)基于這份元數(shù)據(jù)進(jìn)行項(xiàng)目成本核算。
還有一個(gè)收益就是，組件信息的采集，可以很好的控制單個(gè)TiKV的容量，不會(huì)再出現(xiàn)單個(gè)集群容量一直增長(zhǎng)，然后觸發(fā)機(jī)器的磁盤告警DBA才感知到。有了這個(gè)采集的數(shù)據(jù)后，可以設(shè)置一個(gè)TiKV容量上限，比如500GB，達(dá)到這個(gè)閾值就發(fā)送告警給DBA準(zhǔn)備擴(kuò)容。這樣能很好的避免因機(jī)器磁盤告警而接收大量告警信息（單機(jī)多實(shí)例），也能提供一個(gè)很好的緩沖時(shí)間讓DBA來處理。
總結(jié)起來就是，能很好的將機(jī)器/集群/組件管理起來，能合理有效的進(jìn)行資源調(diào)度，也為實(shí)現(xiàn)自動(dòng)化提供了基礎(chǔ)數(shù)據(jù)。
3.2 機(jī)器資源管理
將所有機(jī)器信息保存到表里，定期采集硬件資源使用情況。這么做能獲得如下兩點(diǎn)收益：
- 第一是對(duì)已有環(huán)境進(jìn)行rebalance。有了元數(shù)據(jù)信息，就可以很好的展開rebalance工作了。最終收益很明顯，既提高了資源利用率，還降低了15%的機(jī)器資源。
- 第二是能合理有效的進(jìn)行資源調(diào)度，為實(shí)現(xiàn)自動(dòng)化提供了基礎(chǔ)數(shù)據(jù)。（同元數(shù)據(jù)管理）
元數(shù)據(jù)管理和機(jī)器資源管理，這兩部分工作既降低了成本也提升了工作效率同時(shí)也是監(jiān)控的兜底策略，會(huì)基于這兩個(gè)數(shù)據(jù)表進(jìn)行監(jiān)控：（1）進(jìn)程是否正常。（2）機(jī)器是否正常。
3.3 全面升級(jí)
將所有2.1集群升到4.0.13。
為了更好的管理集群，在升級(jí)前還做了一些規(guī)范化。第一是端口規(guī)劃，因?yàn)門iDB組件太多，一個(gè)集群至少需要6種組件，涉及到十多個(gè)端口，所以做了端口規(guī)劃，端口采用2+3的格式，前兩位表示組件名，后三位表示集群編號(hào)。即：前兩位一樣表示同一類組件，后三位一樣表示同一個(gè)集群。這樣就可以很好的實(shí)現(xiàn)規(guī)范化管理。
比如有一個(gè)001編號(hào)的集群，集群信息如下：
|
角色 |
數(shù)量 |
端口 |
部署目錄 |
域名 |
備注 |
|
pd |
3 |
13001/14001 |
/path/pd-13001 |
tdb.13001.com |
dashboard的域名 |
|
tidb |
3 |
15001/16001 |
/path/tidb-15001 |
tdb.15001.com |
對(duì)外服務(wù)的域名 |
|
tikv |
3 |
17001/18001 |
/path/tikv-17001 | ||
|
alertmanager |
1 |
21001 |
/path/alertmanager-21001 |
tdb.21001.com |
alertmanager的域名 |
|
prometheus |
1 |
19001 |
/path/prometheus-19001 |
tdb.19001.com |
prometheus的域名 |
|
grafana |
1 |
20001 |
/path/grafana-20001 |
tdb.20001.com |
grafana的域名 |
|
exporter |
n |
11001/12001 |
/path/monitor-11001 |
每個(gè)機(jī)器都會(huì)部署 |
- 我們每個(gè)集群的監(jiān)控告警都是獨(dú)立的組件，原因是在使用Alertmanager過程中發(fā)現(xiàn)有時(shí)候A集群的告警信息的instance的值是B集群的instance，為了避免出現(xiàn)這種問題，我們每個(gè)集群的監(jiān)控告警組件都是獨(dú)立的。
- 另外我們會(huì)提供5個(gè)域名，分別對(duì)應(yīng)到TiDB對(duì)外服務(wù)，Dashboard，Grafana，Prometheus，Alertmanager。
- 僅需要提供集群編號(hào)，就可以快速獲取各組件的端口號(hào)及域名，看到部署目錄就可以知道是哪個(gè)集群的哪個(gè)組件。
- 需要注意的是，如果將Dashboard暴露給業(yè)務(wù)使用（業(yè)務(wù)很喜歡訪問慢查詢平臺(tái)），建議是創(chuàng)建獨(dú)立的賬戶，因該平臺(tái)強(qiáng)制要求使用root，所以可以針對(duì)PD組件的幾個(gè)機(jī)器單獨(dú)創(chuàng)建root賬號(hào)，這個(gè)root的密碼跟DBA使用的root進(jìn)行區(qū)別。可以避免管理員賬戶泄露的問題，但是帶來新的問題就是賬戶管理變得復(fù)雜了。
全部完成升級(jí)后。整體性能提升30%-50%，解決了抽數(shù)帶來的影響，升級(jí)以后暫時(shí)沒有收到因抽數(shù)導(dǎo)致影響到業(yè)務(wù)的反饋，在升級(jí)前幾乎每?jī)蓚€(gè)月都會(huì)有至少一次因?yàn)槌閿?shù)導(dǎo)致業(yè)務(wù)受影響。
3.4 告警改造
支持短信、語(yǔ)音告警，并實(shí)現(xiàn)告警收斂、抑制，告警升級(jí)。大大降低告警條數(shù)（條數(shù)至少能降低60%），節(jié)約告警資源。
收斂和抑制目的是降噪。
告警升級(jí)主要是為了降低告警成本，升級(jí)分如下幾個(gè)維度：
- 第一：介質(zhì)升級(jí)。郵件 --> 企業(yè)微信 --> 短信 --> 電話（同一個(gè)告警項(xiàng)發(fā)送超過3次就向上升級(jí)一個(gè)介質(zhì)，具體可以根據(jù)需求定義）。
- 第二：接收人升級(jí)。一級(jí) --> 二級(jí) --> leader。
- 第三：按照時(shí)間升級(jí)。工作時(shí)間通過郵件/企業(yè)微信發(fā)送告警，工作時(shí)間之外通過短信/電話發(fā)送告警。
詳情請(qǐng)看這篇文章 https://mp.weixin.qq.com/s?__biz=MzIwMjk1ODMzMw==&mid=2247487848&idx=1&sn=0a6f76ca4f8f44c8fcd9b34be3c0f07b&chksm=96d7e5faa1a06cecf916141897b3faad11f93f3899c6d21ef24e09414a23cb035ae7670334f2#rd
4 實(shí)現(xiàn)自動(dòng)化
分布式集群有很多優(yōu)點(diǎn)，但是對(duì)DBA來說也增加了運(yùn)維復(fù)雜度，有些集群幾十上百個(gè)節(jié)點(diǎn)，全靠人工去管理運(yùn)維無疑是很痛苦。
轉(zhuǎn)轉(zhuǎn)現(xiàn)在基本完成了自動(dòng)化，收益也很明顯，這部分主要是想分享一下注意事項(xiàng)或者遇到的問題，僅供參考。
4.1 需求工單化
這部分主要是在平臺(tái)通過工單的方式實(shí)現(xiàn)了業(yè)務(wù)的日常的需求，降低了溝通成本，實(shí)現(xiàn)了業(yè)務(wù)需求審計(jì)，還能減少DBA的工作量。
目前支持如下工單類型。
工單類型
（1）集群部署工單
在4.0版本中，部署一個(gè)新集群比較麻煩的是拓?fù)湮募纳?，倒不是有多?fù)雜，而是因?yàn)橐粋€(gè)集群的組件太多，每種組件對(duì)硬件的要求又有些區(qū)別。
比如Grafana，Alertmanager這種不需要IO，PD，TiKV，TiFlash對(duì)IO又要求比較高，另外還需要根據(jù)服務(wù)的重要程度進(jìn)行合理的規(guī)劃，重要的服務(wù)單獨(dú)部署或者盡可能的減少節(jié)點(diǎn)數(shù)，需要考慮的點(diǎn)參考維度有點(diǎn)多。
以上只是針對(duì)部署集群需要關(guān)注的點(diǎn)，還有一些額外的考慮點(diǎn)，或者說操作細(xì)節(jié)?？偨Y(jié)起來如下：
- 為各個(gè)角色選擇合適的機(jī)器，完成拓?fù)湮募?，然后部署集群?/li>
- 初始化集群，創(chuàng)建業(yè)務(wù)用戶，業(yè)務(wù)域名。
- 配置Grafana，Prometheus，Alertmanager，Dashboard等平臺(tái)，創(chuàng)建必要的用戶，以及Grafana，Dashboard權(quán)限控制，以及功能驗(yàn)證測(cè)試等。
- 集群信息入庫(kù)，將必要的信息同步到業(yè)務(wù)側(cè)。
所以實(shí)現(xiàn)工單化，不僅輕松解決資源調(diào)度問題，提升機(jī)器資源利用率，還可以大大提升效率，避免操作出錯(cuò)或者遺漏。尤其是功能驗(yàn)證，萬一業(yè)務(wù)上線以后才發(fā)現(xiàn)問題，影響面就比較大了。
新建集群
通過sic判斷集群重要等級(jí)，預(yù)估QPS，TPS作為輔助參考項(xiàng)，最終根據(jù)評(píng)分為其分配合理的機(jī)器進(jìn)行集群部署。
（2）數(shù)據(jù)恢復(fù)工單
這類需求在工作中倒不是很多，但是一旦遇到就會(huì)比較緊急。實(shí)現(xiàn)這類工單后，不僅可以降低溝通成本，降低故障的影響時(shí)間，也能降低人力成本。
目前支持兩個(gè)維度的數(shù)據(jù)恢復(fù)。
- 一種是基于快照，如果恢復(fù)需求的時(shí)間點(diǎn)在GC時(shí)間之內(nèi)的，就直接通過快照進(jìn)行數(shù)據(jù)恢復(fù)，所以這類需求恢復(fù)速度較快。
- 一種是基于備份文件，如果恢復(fù)的時(shí)間點(diǎn)位不在GC時(shí)間之內(nèi)的，就只能選擇最接近該時(shí)間點(diǎn)的備份文件來恢復(fù)了。
目前這兩類維度都支持整庫(kù)（一個(gè)工單僅限單庫(kù)），單表或者多表?；诳煺盏倪€支持帶特定條件，基于備份文件的不支持帶條件。所以相對(duì)來說基于快照的復(fù)雜一些，特別是多表需要恢復(fù)到某一個(gè)時(shí)間點(diǎn)，且是帶條件恢復(fù)（單表部分?jǐn)?shù)據(jù)）。
比如一個(gè)訂單，涉及多個(gè)表，需要將多個(gè)表某些訂單號(hào)的數(shù)據(jù)恢復(fù)到特定時(shí)間點(diǎn)。
由此可見，基于快照的恢復(fù)是比較靈活的，用戶可以選單庫(kù)，或者單表，還可以選擇多表，由于我們并不知道用戶需要恢復(fù)幾張表，所以帶查詢條件的邏輯應(yīng)該是動(dòng)態(tài)的，即當(dāng)用戶選擇了某個(gè)表，就會(huì)彈出改表的查詢條件輸入框，有幾個(gè)表就有幾個(gè)輸入框，根據(jù)提示輸入到對(duì)應(yīng)的表即可，如下圖所示。
數(shù)據(jù)恢復(fù)
（3）TiCDC工單
轉(zhuǎn)轉(zhuǎn)公司有一種特殊業(yè)務(wù)需求，需要將業(yè)務(wù)的數(shù)據(jù)抽取到大數(shù)據(jù)平臺(tái)，主要是給業(yè)務(wù)提供經(jīng)營(yíng)數(shù)據(jù)分析、用戶行為和畫像資產(chǎn)沉淀以及一些趨勢(shì)預(yù)測(cè)。
如果是MySQL直接做一個(gè)專門提供數(shù)據(jù)抽取的從庫(kù)就行了，但是TiDB不行，雖然可以暴露一個(gè)TiDB節(jié)點(diǎn)給大數(shù)據(jù)進(jìn)行數(shù)據(jù)抽取，但是本質(zhì)上還是對(duì)同一組TiKV進(jìn)行操作，所以抽數(shù)操作很容易引起業(yè)務(wù)的抖動(dòng)。
現(xiàn)在我們提供了兩種方案給業(yè)務(wù)進(jìn)行選擇，優(yōu)先可以選擇TiCDC，如果TiCDC不能滿足的情況下可以使用TiFlash。
ticdc
對(duì)于已經(jīng)存在cdc任務(wù)，只需更新配置即可，另外需要注意下游如果是kafka的話，數(shù)據(jù)包的大小，要求跟kafka的最大值配置一致，否則可能會(huì)報(bào)錯(cuò)，尤其是TiDB端擴(kuò)大表結(jié)構(gòu)的場(chǎng)景。
對(duì)我們來說，TiCDC需求真的太需要實(shí)現(xiàn)工單化了。那些需要抽數(shù)的業(yè)務(wù)，幾乎新增一個(gè)表就需要更新TiCDC的任務(wù)，之前都是郵件溝通，如今實(shí)現(xiàn)工單后，對(duì)業(yè)務(wù)，對(duì)大數(shù)據(jù)團(tuán)隊(duì)，又或者是DBA都是十分方便的，降低了三方的溝通成本，提升工作效率。
（4）TiFlash工單
需求同TiCDC工單。
tiflash
從成本上考慮，TiCDC不需要額外的存儲(chǔ)空間，所以更優(yōu)，也更受歡迎。但是存在一定的風(fēng)險(xiǎn)，比如TiCDC到下游的同步鏈路出現(xiàn)問題（上游TiDB業(yè)務(wù)進(jìn)行調(diào)整可能會(huì)導(dǎo)致同步中斷），那么下游就會(huì)無法獲取增量數(shù)據(jù)。
TiFlash則不會(huì)有這個(gè)問題，但是需要犧牲一定的存儲(chǔ)空間，業(yè)務(wù)成本會(huì)有所提升，需要業(yè)務(wù)自己去權(quán)衡。
4.2 操作平臺(tái)化
這部分主要是在平臺(tái)通過頁(yè)面操作實(shí)現(xiàn)了日常的管理，降低了運(yùn)維成本，實(shí)現(xiàn)了操作審計(jì)，還能避免一定的人為操作失誤。
（1）節(jié)點(diǎn)管理
這部分涉及節(jié)點(diǎn)的啟動(dòng)、關(guān)閉、重啟、下線、維護(hù)等。節(jié)點(diǎn)啟停、重啟流程比較簡(jiǎn)單，這里不做過多介紹。
節(jié)點(diǎn)管理
只有當(dāng)節(jié)點(diǎn)處于關(guān)閉狀態(tài)才會(huì)有啟動(dòng)選項(xiàng)。另外需要注意的是，重啟操作已經(jīng)改成reload，這樣對(duì)業(yè)務(wù)的影響相對(duì)小一些。前提是要評(píng)估好restart是否等價(jià)于reload（沒有變更配置基本不會(huì)有什么問題）。
下線和維護(hù)操作需要注意如下幾個(gè)事項(xiàng)：
節(jié)點(diǎn)管理
- 下線的目標(biāo)節(jié)點(diǎn)是否是該角色的最后一個(gè)節(jié)點(diǎn)，或者是否滿足raft協(xié)議的最低要求，如果是則不能直接下線，需要人工介入。
- 維護(hù)操作主要是需要聯(lián)動(dòng)一下告警靜默，因?yàn)榫S護(hù)操作本身是計(jì)劃內(nèi)操作，對(duì)于不必要的告警可以提前規(guī)避掉。
對(duì)于PD，TiKV等組件對(duì)數(shù)量是有要求的，PD，TiKV最少要求兩個(gè)，所以當(dāng)集群只剩兩個(gè)節(jié)點(diǎn)的時(shí)候是不允許下線的，需要DBA介入操作，當(dāng)然還有DM-worker，TiFlash等組件也是有最低數(shù)量要求，需要根據(jù)實(shí)際情況進(jìn)行判斷。
（2）擴(kuò)容管理
擴(kuò)容分兩種情況，一種是主動(dòng)擴(kuò)容，一種是自動(dòng)擴(kuò)容。這個(gè)小結(jié)是介紹主動(dòng)擴(kuò)容，至于自動(dòng)擴(kuò)容后文會(huì)介紹。
擴(kuò)容功能比較靈活，支持多角色同時(shí)擴(kuò)容，節(jié)點(diǎn)個(gè)數(shù)可配置，目標(biāo)地址也可配置，如下圖所示：
擴(kuò)容
未指定地址的話就由系統(tǒng)默認(rèn)分配合理的目標(biāo)地址。
（3）下線管理
下線要求是串行操作，即一個(gè)集群在同一個(gè)時(shí)間只能有一個(gè)節(jié)點(diǎn)被下線，等待下線后才能下線第二個(gè)節(jié)點(diǎn)。另外，如果是存儲(chǔ)節(jié)點(diǎn)（TiKV，TiFlash，Pump），需要等待數(shù)據(jù)遷移完畢后，執(zhí)行完集群調(diào)整（prune）操作才算下線完成。
下線
需要考慮一下異常節(jié)點(diǎn)的下線，即機(jī)器宕機(jī)不可恢復(fù)的情況，所以我們?cè)黾恿艘粋€(gè)強(qiáng)制下線的選項(xiàng)來處理此類異常場(chǎng)景。
（4）告警管理
告警跟運(yùn)維工作息息相關(guān)，一個(gè)好的告警管理平臺(tái)不僅能提升運(yùn)維的效率，還能提升工作舒適度及生活質(zhì)量。
我們的告警管理平臺(tái)現(xiàn)在功能比較簡(jiǎn)單，后續(xù)會(huì)慢慢豐富。
- 支持預(yù)先配置告警靜默，比如將對(duì)某個(gè)集群進(jìn)行維護(hù)，可以先將該集群的告警進(jìn)行靜默。
告警管理
靜默時(shí)間最長(zhǎng)不允許超過24小時(shí)，默認(rèn)是2小時(shí)，這樣可以避免因遺忘導(dǎo)致該告警項(xiàng)被長(zhǎng)時(shí)間靜默。
- 支持針對(duì)已經(jīng)告警的項(xiàng)進(jìn)行靜默。這部分邏輯是將所有告警項(xiàng)展示出來，供用戶選擇。
如下是正在告警列表展示頁(yè)
告警管理-告警列表
支持一鍵靜默，即：正在告警的項(xiàng)全部靜默。
如下是靜默規(guī)則列表展示頁(yè)，正在運(yùn)行的靜默規(guī)則支持刪除及禁用，禁用狀態(tài)的允許重新啟用。
告警管理-靜默規(guī)則列表
（5）慢查詢告警
這個(gè)功能是統(tǒng)計(jì)單位時(shí)間內(nèi)慢查詢條目增長(zhǎng)量，當(dāng)達(dá)到告警閾值就會(huì)觸發(fā)告警，用戶可以設(shè)置統(tǒng)計(jì)的時(shí)間范圍，以及慢查詢閾值，還有告警閾值。
慢查詢告警-添加規(guī)則
集群的慢查詢閾值大于用戶定義的規(guī)則的慢查詢最小閾值，會(huì)將集群的慢查詢閾值設(shè)置為該閾值。如集群慢查詢閾值是300ms，用戶定義告警閾值是200ms，這時(shí)候會(huì)將集群的慢查詢閾值設(shè)置為200ms。
如下是規(guī)則列表展示頁(yè)，支持規(guī)則禁用及刪除，禁用后可以重新啟用。
慢查詢告警-規(guī)則展示頁(yè)
4.3 其他輔助功能
（1）進(jìn)程監(jiān)控
進(jìn)程監(jiān)控
因線上機(jī)器基本都是單機(jī)多實(shí)例，有時(shí)候會(huì)出現(xiàn)因?yàn)槟硞€(gè)實(shí)例而影響了整個(gè)機(jī)器的性能，在沒有進(jìn)程級(jí)別的監(jiān)控下，對(duì)我們排查定位問題十分痛苦，為解決這一個(gè)痛點(diǎn)，我們開發(fā)了進(jìn)程維度的監(jiān)控系統(tǒng)，這樣可以很好的協(xié)助運(yùn)維人員排查定位機(jī)器資源跑滿等問題。
進(jìn)程級(jí)別的資源監(jiān)控，包括但是不限于CPU, 內(nèi)存, 磁盤IO, 網(wǎng)絡(luò)流量，功能還在繼續(xù)豐富。具體實(shí)現(xiàn)可以參考這個(gè)文章 https://mp.weixin.qq.com/s?__biz=MzIwMjk1ODMzMw==&mid=2247487654&idx=1&sn=0722b7e216cb2f887eea2d8f874faa88&chksm=96d7e434a1a06d22b2a52a87b4bcc8a2fbc52218802ceefa6f243a0bb71a0ea02fd521c67395#rd
進(jìn)程監(jiān)控
會(huì)記錄每個(gè)進(jìn)程的資源使用情況，其中網(wǎng)絡(luò)數(shù)據(jù)是做了限制，只有達(dá)到閾值才會(huì)采集，所以會(huì)出現(xiàn)空白頁(yè)情況。另外網(wǎng)絡(luò)傳輸數(shù)據(jù)會(huì)記錄源端到目的端信息。
（2）趨勢(shì)監(jiān)控
隨著時(shí)間的推移，業(yè)務(wù)數(shù)據(jù)也在不斷的增長(zhǎng)。那么問題來了，這個(gè)增長(zhǎng)是否符合預(yù)期？按照這個(gè)增量，磁盤空間能支持多長(zhǎng)時(shí)間？為了解決這兩個(gè)問題，我們采取了趨勢(shì)分析的方案，提前監(jiān)控，分析增長(zhǎng)趨勢(shì)，對(duì)于增長(zhǎng)異常的集群會(huì)和業(yè)務(wù)進(jìn)行溝通確認(rèn)，對(duì)于磁盤空間臨近告警線會(huì)提前遷移。
進(jìn)程監(jiān)控
- 增量告警，當(dāng)數(shù)據(jù)目錄在三日內(nèi)連續(xù)單日增長(zhǎng)超過20GB，每個(gè)月增量超過200GB就會(huì)發(fā)送告警給業(yè)務(wù)，請(qǐng)業(yè)務(wù)進(jìn)行確認(rèn)。
- 全量告警，當(dāng)數(shù)據(jù)目錄達(dá)到告警閾值就給DBA發(fā)送告警。
（3）自動(dòng)運(yùn)維
- 自適應(yīng)遷移
當(dāng)機(jī)器準(zhǔn)備達(dá)到內(nèi)存告警閾值，磁盤告警閾值，就自動(dòng)遷移。
- 自適應(yīng)擴(kuò)容
當(dāng)單個(gè)TiKV容量達(dá)到800GB就自動(dòng)進(jìn)行擴(kuò)容。
不管是自適應(yīng)遷移還是擴(kuò)容，都可以減少DBA的工作量，也能在一定程度上減少告警量。對(duì)于擴(kuò)容，既控制了單個(gè)TiKV的大小，對(duì)于系統(tǒng)性能也會(huì)有一定的提升。
單節(jié)點(diǎn)TiKV太大，不利于管理。在節(jié)點(diǎn)下線的場(chǎng)景下會(huì)拉長(zhǎng)數(shù)據(jù)遷移的時(shí)間，在節(jié)點(diǎn)離線的場(chǎng)景下，會(huì)拉長(zhǎng)生成新副本的時(shí)間。
5 寫在最后
本文介紹了TiDB在轉(zhuǎn)轉(zhuǎn)公司的發(fā)展歷程，從調(diào)研測(cè)試到投產(chǎn)使用，從命令行運(yùn)維到自動(dòng)化平臺(tái)管理，將業(yè)務(wù)日常需求基本實(shí)現(xiàn)了工單化，DBA日常管理維護(hù)的操作基本都實(shí)現(xiàn)了平臺(tái)化。
一切自動(dòng)化的前提是先實(shí)現(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ù)庫(kù)平臺(tái)開發(fā)。
標(biāo)題名稱：TiDB在轉(zhuǎn)轉(zhuǎn)公司的發(fā)展歷程
標(biāo)題鏈接：http://fisionsoft.com.cn/article/cdigdcj.html
