直播回顧|數(shù)據(jù)庫運維不再難，數(shù)據(jù)庫“自動駕駛”技術(shù)已到來-創(chuàng)新互聯(lián)

騰訊云數(shù)據(jù)庫國產(chǎn)數(shù)據(jù)庫專題線上技術(shù)沙龍正在火熱進行中，3月26日郝志剛的分享已經(jīng)結(jié)束，沒來得及參與的小伙伴不用擔(dān)心，以下就是直播的視頻和文字回顧。

目前成都創(chuàng)新互聯(lián)已為上千的企業(yè)提供了網(wǎng)站建設(shè)、域名、網(wǎng)頁空間、網(wǎng)站托管維護、企業(yè)網(wǎng)站設(shè)計、臺山網(wǎng)站維護等服務(wù)，公司將堅持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

關(guān)注“騰訊云數(shù)據(jù)庫”公眾號，回復(fù)“0326郝志剛”，即可下載直播分享PPT。

瞬間從億條SQL中找到問題所在：TDSQL自動化運營體系_騰訊視頻

前言

“赤兔”平臺是TDSQL提供的產(chǎn)品服務(wù)之一，它從管理員視角提供TDSQL的全部運維功能和上百項數(shù)據(jù)庫狀態(tài)監(jiān)控指標(biāo)的展示，讓數(shù)據(jù)庫管理員日常90%以上的操作均可通過界面化完成，同時更方便定位排查問題。

扁鵲系統(tǒng)是TDSQL面向云市場推出的一款針對數(shù)據(jù)庫性能/故障等問題的自動化分析并為用戶提供優(yōu)化/解決方案的產(chǎn)品，它提供包括數(shù)據(jù)采集、實時檢測、自動處理、性能檢測與健康評估、SQL性能分析、業(yè)務(wù)診斷等多種智能工具的集合。

在數(shù)據(jù)庫日常應(yīng)用中，常常會面對如存儲容量和性能需求急速增長帶來的性能等異常問題。對于引起數(shù)據(jù)庫異常的問題SQL，這時扁鵲可以通過一鍵診斷分析，幫助用戶快速進行智能檢測和分析，快速將問題定位，同時給出優(yōu)化建議。在扁鵲的幫助下，DBA可以從日常繁雜的數(shù)據(jù)庫運維工作中解脫出來。在支持騰訊會議需求量暴漲，數(shù)據(jù)庫遇到性能問題過程中，扁鵲智能運維曾幫助DBA快速在億條SQL中定位到了問題SQL，并提供優(yōu)化意見，將數(shù)據(jù)庫的性能問題及時扼殺在萌芽當(dāng)中。系統(tǒng)顯示，經(jīng)過優(yōu)化，99%的SQL都消除了性能瓶頸。

“扁鵲”在迭代演進過程中沉淀了騰訊數(shù)據(jù)庫實踐中積累的海量運維規(guī)則知識庫，可幫助DBA迅速排查日常常見異常，而結(jié)合騰訊云海量數(shù)據(jù)+機器學(xué)習(xí)能力，扁鵲可對未知問題進行主動分析檢測，并告知客戶，盡可能將大部分異常在發(fā)生之前就發(fā)出預(yù)警，將風(fēng)險降到最低，提升DB持續(xù)可靠地服務(wù)各種不同業(yè)務(wù)場景的特性能力。

“赤兔”和“扁鵲”這一套組合拳既滿足高星級業(yè)務(wù)的精細化運維，又能輕松應(yīng)對大量的普通數(shù)據(jù)庫運維需求，更好地幫助用戶降低運維成本。

大家好，我是騰訊云TDSQL高級DBA郝志剛。今天分享的主題是TDSQL自動化運營體系。聽過我們前面系列課程的同學(xué)應(yīng)該對TDSQL的架構(gòu)原理等有比較詳細的了解。而回到現(xiàn)實的工作中處理各種問題，還是要埋頭解決各種運營問題。所以今天我們介紹一下TDSQL的自動化運營體系，看TDSQL自動化運營體系能為廣大DBA或者運維人員帶來什么。事實上TDSQL自動化運營體系可以幫助DBA的工作更放松一點、輕松一點，而不是想象中比較苦、比較累的工作，希望對大家有幫助。

我演講分為四個章節(jié)：

第一個章節(jié)是TDSQL自動化運營體系，包括架構(gòu)、支持的功能特性等。第二、第三章會基于DBA的兩大事務(wù)體系——日常處理的事務(wù)，以及故障分析類事務(wù)，結(jié)合一些典型案例來介紹TDSQL自動化運營體系是如何幫助大家高效、便捷、自動化地解決這些事務(wù)問題的。第四章做簡單的總結(jié)。

TDSQL自動化運營體系

第一章節(jié)主要括三部分內(nèi)容，一方面是對DBA日常工作進行梳理。第二介紹TDSQL自動化運營平臺“赤兔”。第三介紹數(shù)據(jù)庫后臺如何實現(xiàn)自動化運營，介紹背后原理性的東西，幫助大家理解TDSQL是如何怎么實現(xiàn)自動化運營的。

1.1 DBA的日常工作復(fù)雜繁瑣？赤兔一鍵搞定

大家看到這個圖會非常煩躁，這是日常DBA要處理各種問題：比如一個業(yè)務(wù)要上線，需要創(chuàng)造一個實例；比如機器要擴容，需要緊急申請權(quán)限；不小心弄錯數(shù)據(jù)，需要趕緊回檔；或者是表結(jié)構(gòu)需要變更………這張圖里就是DBA日常要面臨的復(fù)雜量大的問題處理。從中我們也可以總結(jié)出兩個特點：第一個每個DBA對于處理這些都會有一套自己的邏輯。比如我做一個DDL，可能這個DDL可以這么操作，另外一個DDL要用另外一個工具，這些操作的方法不夠標(biāo)準(zhǔn)而且不夠穩(wěn)定；也許今天用的這個方法明天用就不靈了——它的穩(wěn)定性難以保證。

第二，我們做這個事情需要很多后臺操作來配合，后臺操作對于DBA來說非常頻繁。一方面可能習(xí)慣于這種操作，但是這個方式帶來的風(fēng)險會比較大，我們敲下一條命令的時候有沒有感覺很心慌，它的后果是什么？以往沒有統(tǒng)一的平臺來保證做這個事情是非常安全的。

所以TDSQL致力于解決這兩個難點：

• 第一個是流程要標(biāo)準(zhǔn)化；

• 另一方面是效率提升。

我們不需要后臺操作，而是前臺點一點就可以解決DBA的大部分事務(wù)。

DBA日常工作大致可以分為兩類：一類是日常類事務(wù)，另一類是故障類事務(wù)。日常類就是平時業(yè)務(wù)的各種需求，DBA通過一些腳本、自動化工具可以做的事情；故障類就是比如我們遇到一個難題，“數(shù)據(jù)庫連不上”，“數(shù)據(jù)庫特別慢”，需要看一下為什么。

我們簡單看一下日常類。除了剛才提到的創(chuàng)建實例、DDL在線變更，還有實例下線，這個雖然不常用，但是數(shù)據(jù)庫運營較長一段時間中也是可能遇到的。此外還包括業(yè)務(wù)停運了將數(shù)據(jù)庫清掉然后存放其他數(shù)據(jù)，還有參數(shù)調(diào)整和調(diào)優(yōu)——我覺得這個超時時間可能設(shè)得不太合理，業(yè)務(wù)側(cè)要這么設(shè)置更改，等等。而擴容更是在所難免——業(yè)務(wù)數(shù)據(jù)量特別大，或者請求量特別多，實例撐不住了就要擴容。還有讀寫分離，還有重做備機、備份手工切換、在線SQL……

故障類指的是問題診斷類型：業(yè)務(wù)說DB連不上，幫忙看一下為什么；還有監(jiān)控預(yù)警——如果DB有異常我們要自動發(fā)現(xiàn)這個問題，不然非常被動。系統(tǒng)分析——可能數(shù)據(jù)庫運行慢了，但是還不影響使用性，看一下能不能有優(yōu)化的空間；自動容災(zāi)切換就是保證用戶的高可用；數(shù)據(jù)回檔防止數(shù)據(jù)誤刪；日常巡檢是針對性地發(fā)現(xiàn)一些潛在問題。

以上大概介紹了一些事務(wù)，但是這些并不是說完全代表TDSQL自動化運營平臺支持的功能，這只是簡單列舉了幾個比較重要的案例。言歸正傳，這些事情TDSQL是怎么自動化完成的？TDSQL把這些功能呈現(xiàn)在數(shù)據(jù)庫運營平臺“赤兔”上，所有用戶包括DBA，在赤兔上就可以完成以上所有的操作，而且全是自動化的；赤兔又會和TDSQL打通，赤兔會把流程以任務(wù)的形式發(fā)給TDSQL，TDSQL集群會自動幫用戶完成這個事情，并且反饋給赤兔，然后用戶就可以看到這個操作的結(jié)果。

所以赤兔平臺整個流程就是把每一項日常類事務(wù)、故障分析類事務(wù)封裝成一個個自動化流程，然后打通用戶的需求和TDSQL后臺操作的流程，幫助大家能夠利用平臺高效安全地解決日常工作中遇到的問題。

1.2 TDSQL-赤兔自動化處理原理

接下來介紹TDSQL后臺如何完成自動化流程處理，包括介紹其中的自動化處理流程以及核心的模塊。

這個圖如果大家聽過前面一系列的分享應(yīng)該是有所了解，但是今天這個圖和之前的架構(gòu)圖稍微有一點不一樣，我們依次看一下：

用戶的請求在赤兔平臺以任務(wù)的形式發(fā)給后臺的OSS（OSS是TDSQL對外的接口），OSS又會做一個分發(fā)，把一部分的任務(wù)寫在MetaCluster里面。MetaCluster寫成任務(wù)之后左邊有scheduler和onlineddl兩個模塊會監(jiān)控監(jiān)聽各自的任務(wù)節(jié)點，有新的任務(wù)就進行處理。

OSS把問題分析類型的任務(wù)會直接發(fā)到扁鵲——TDSQL自動化運營體系中的智能分析平臺。扁鵲負責(zé)問題智能分析，它利用監(jiān)控采集的數(shù)據(jù)——比如DBA的狀態(tài)、主備切換等TDSQL監(jiān)控數(shù)據(jù)，以及扁鵲還會實際訪問數(shù)據(jù)節(jié)點，采集它認為需要支撐分析實例的數(shù)據(jù)。扁鵲在TDQSL框架里是一個新的模塊。另外還有一個模塊是onlineddl，它專門獨立處理DDL請求。除了這兩種請求類型，其他的任務(wù)基本由scheduler模塊完成。

右下角有一條線是Agent——每個節(jié)點都由Agent進程模塊來監(jiān)控甚至完成輔助性動作，scheduler無法直接接觸所以Agent也會輔助完成剛才提到的流程。它也是通過MetaCluster獲取自己需要的信息進行處理，處理完之后響應(yīng)反饋給scheduler甚至其他模塊。

所以這個圖有三個核心模塊來處理日常的流程：一個是扁鵲，這個是問題分析模塊。onlineddl處理DDL請求，以及TDSQL各個模塊后面的角色以及任務(wù)的處理。TDSQL自動化運營流程和框架就介紹到這里。

TDSQL日常事務(wù)處理自動化

接下來講第二章，TDSQL日常事物處理自動化。

剛才講過我們把DBA任務(wù)分成兩類，一類是日常類，一類是故障類。先講日常類的處理自動化，這個章節(jié)會選取兩個日常非常常見的場景分析，分享TDSQL是如何解決這些問題的。

第一是重做DB節(jié)點功能，第二個是在線DDL功能，第三是TDSQL在自動化流程里如何做安全保障。

2.1 重做DB節(jié)點功能

第一節(jié)重做DB節(jié)點。大家可能會想為什么重做DB節(jié)點？這個場景比較常見，雖然它不是每天都發(fā)生，但是它隔一段時間就會發(fā)生，而且這個事情也是比較重要的。比如機器故障了機器修復(fù)可能需要一點時間，機器修復(fù)之后需要重新加入集群，數(shù)據(jù)可能就丟失；或者數(shù)據(jù)非常舊，已經(jīng)追不上了，我們需要對這個數(shù)據(jù)節(jié)點進行重做；另外，如果卡頓無法恢復(fù)了我們就需要對數(shù)據(jù)節(jié)點進行重做，恢復(fù)節(jié)點的功能。

這個怎么做呢？我們可以看到這樣一張圖：

首先系統(tǒng)會發(fā)起重做流程——這個流程在赤兔上進行完成，赤兔會把任務(wù)發(fā)給TDSQL集群。TDSQL集群針對這個任務(wù)有四個步驟：

1. 為什么要重做DB節(jié)點呢？因為機器上可能殘留一些數(shù)據(jù)，我們需要清掉，刪除限速。2. 拉取鏡像。無論是邏輯上還是物理上，都需要拉過來到節(jié)點上，作為數(shù)據(jù)的基準(zhǔn)。3. 然后是加載鏡像。4. 最后是恢復(fù)同步。

可能大家在日常的運維或者是處理事情的時候都是這個流程，它基本比較符合大家的習(xí)慣。不同的是可能以往較多的是手工處理，而赤兔在這里一鍵就可以發(fā)下去。

整個流程做了非常好的優(yōu)化：

赤兔提供了主節(jié)點保護，因為假如是1主2備架構(gòu)，為了防止出錯，系統(tǒng)限制了不能直接在主節(jié)點實施重做。此外還形成了實時節(jié)點信息，例如這個節(jié)點是不是故障狀態(tài)？延遲多少？……通過這個優(yōu)化我們可以實時判斷是不是正確的節(jié)點。

再看重裝DB步驟。第一步會刪除限速，而且這個數(shù)據(jù)往往是非常大的，幾百G甚至上T，所以我們要控制速度，如果快速刪除會導(dǎo)致IO較高，而且一臺機器上是多租戶的架構(gòu)，可能會影響其他實例的正常運行，所以要限速刪除。另一方面，刪除之后要把數(shù)據(jù)進程重新安裝，安裝的時候會自動拉取DB參數(shù)。因為DB在運行過程中可能很多參數(shù)已經(jīng)被改動，安裝之后的參數(shù)要保持和原來的參數(shù)一致，所以安裝過程要自動拉取。而且，有時候參數(shù)列表會很長有十幾個，手動操作是一個容易失誤且工作量極大的事情。

另外，拉取鏡像步驟，這是耗時最長而且是比較重要的一步，這里面做了三個優(yōu)化：第一是選擇最優(yōu)的數(shù)據(jù)源，比如像一主幾備的情況下，每個備機都有延遲狀況，我們可能會選擇延遲最小的，這個數(shù)據(jù)是最新的，如果是一備的情況則優(yōu)先選擇備機。而這個過程可能會對業(yè)務(wù)的讀寫有影響，所以要選擇最優(yōu)的數(shù)據(jù)。第二拉取進程——比如同時做了很多流程不能同時拉取，一個是網(wǎng)卡流量會跑滿，另外是由于有大量數(shù)據(jù)寫入，就是IO負載比較重。所以要互斥，這樣影響是最小的。第三是做壓縮加速——這個地方主要是在于數(shù)據(jù)源，系統(tǒng)會把數(shù)據(jù)拉取的鏡像進行優(yōu)化壓縮，壓縮之后傳到做的節(jié)點上；這樣做的好處一方面是減輕網(wǎng)絡(luò)的壓力，壓縮比大約是三分之一到四分之一。同時，我們可以加速，畢竟傳輸比較小，比如壓縮四分之一傳100兆就是傳過去400兆的數(shù)據(jù)，對提升效率非常有幫助。

最后步驟是建立同步，這里主要是確認同步點以及恢復(fù)同步，這里TDSQL會幫助你自動去做。

所以大家看到，整個流程對用戶來說只需要在赤兔上點擊“發(fā)起重做”就可以自動完成整個流程，不需要過度介入。

我們來看一個重做DB的例子。

上面的圖是一個實錄：可以看到DB節(jié)點有三個，重做節(jié)點就在右下角，點“重做備機”按鈕進入流程，這個頁面可以實時顯示兩個備節(jié)點狀態(tài)，我們可以看到第一個備節(jié)點延遲非常大，這個就是我們需要重做的異常節(jié)點，防止大家誤操作選錯節(jié)點。提交完之后過一段時間會告訴你“重做成功”。整個流程就結(jié)束了。

2.2 在線DDL

我們再看在線DDL功能。

操作DDL非常常見的應(yīng)用，尤其是在業(yè)務(wù)變化非常頻繁、表結(jié)構(gòu)頻繁變化的場景中。為什么要提在線DDL？如果是面對一個普通的小表，那么可以直接做DDL，但是如果面對的是一個數(shù)據(jù)量比較大的表，比如幾十G甚至幾百G，要做一個表結(jié)構(gòu)變更怎么辦？這個時候很有可能影響業(yè)務(wù)請求，所以我們提出要做在線DDL。

在赤兔上，在線DDL也非常簡單：我們在赤兔上提交請求，然后傳輸?shù)絋DSQL模塊實施，一共兩步—熟悉數(shù)據(jù)庫的應(yīng)該比較了解，這兩個步驟一個負責(zé)拷貝數(shù)據(jù)，隨后表數(shù)據(jù)同步完之后再進行切表——新老表進行切換。

TDSQL在這個流程里做了哪些事情？赤兔可以自定義DDL的開始時間。那為什么要做這個事情？DDL雖然是在線，但是也會涉及到拷貝數(shù)據(jù)，特別是在業(yè)務(wù)負載比較高的時候會對業(yè)務(wù)有影響，我們希望在業(yè)務(wù)不繁忙的時候——業(yè)務(wù)一天里的周期一般是固定的，即在業(yè)務(wù)低谷的時候做這個事情，因此平臺支持可以自定義時間，比如白天發(fā)起任務(wù)，晚上一點鐘業(yè)務(wù)低估時再正式運行任務(wù)。

拷貝數(shù)據(jù)。剛才提了拷貝數(shù)據(jù)可能會對業(yè)務(wù)有時耗影響，所以TDSQL會檢測這兩個指標(biāo)：備機延遲檢測與活躍鏈接檢測——超過了會暫停，直到恢復(fù)正常時再繼續(xù)。這兩個指標(biāo)在前臺也可以自定義，不過系統(tǒng)有推薦的默認值，一般不需要更改。

另外是切表流程。這個流程涉及到新老表的切換——把新表切成老表的名字。

切表流程涉及兩個功能應(yīng)用：切表加鎖檢測和保護，以及切表模式自由選擇。第一個，日常中我們很常見的場景是，切表前有一個大的事務(wù)在訪問這張表，查詢了半個小時還沒有跑出來。這個時候要做切表操作就獲取不到元數(shù)據(jù)鎖，同時又阻塞了后面的業(yè)務(wù)請求，后面的業(yè)務(wù)請求會等前面的切表流程才能繼續(xù)。所以TDSQL根據(jù)這個場景做了一個切表加鎖保護——就是說，我們在知道要切表之前，要先看一下請求里有沒有這表的大查詢，有的話就暫時不切，先讓它完成，我們不會把它直接殺掉。開始切的話時間非常短，對用戶最多影響一秒鐘。如果正要發(fā)生切表時，正好有個請求搶在前面讓切表無法執(zhí)行，那系統(tǒng)就自動超時，不影響后面的業(yè)務(wù)SQL。回到數(shù)據(jù)同步狀態(tài)隔一段時間又會發(fā)起切表，而且間隔時間會越來越長，直到可以完成整個DDL操作。

另一個自由選擇功能意味著，切表模式可以選擇手動和自動切表：自動完成也有加鎖保護；手動切表就是拷貝數(shù)據(jù)完成之后不立即切表，而是DBA可以手工在前臺發(fā)起切表操作。

我們看一個在線DDL的例子：

左圖就是在線DDL頁面，通過頁面可以看到表結(jié)構(gòu)，大家點擊“編輯”按鈕就可以修改字段和索引。右圖的頁面里面我們可以看到，剛才提到的參數(shù)設(shè)置都可以自定義，也可以選擇默認值，點擊“確認”后整個過程自動完成。如果選擇手動切表，可以選擇合適的時間完成切表操作。

2.3 TDSQL自動化運營體系的安全性保障

我們看一下安全保護機制，流程自動化了，我們更要保證這里面每一個流程都是安全合理的。

安全性保障不僅限于這些，PPT里選取了部分常見的場景。

權(quán)限申請非常常見：如果有用戶已申請了密碼A，而且程序已經(jīng)使用這個賬戶在運行中，如果再申請這個用戶而使用不同密碼，系統(tǒng)會自動檢查，所以不讓老的密碼被覆蓋掉。

第二類是onlineddl自動保護。

第三個是實例下線，這個我們做了一個隔離定時刪除功能。我們可以先進行隔離，隔離之后訪問數(shù)據(jù)庫的請求都會被拒掉，但是隔離狀態(tài)是可以及時恢復(fù)的，所以我們相當(dāng)于放在一個回收站里，數(shù)據(jù)還沒有清掉，但業(yè)務(wù)訪問不了。過一段時間定時清理，比如7天之后（這個時間長度是可以自定義的）沒有業(yè)務(wù)反饋，則可以清掉，安全下線。

重做DB節(jié)點，在這個環(huán)節(jié)TDSQL提供了主節(jié)點保護的功能機制。擴容，會涉及到TDSQL擴容：把數(shù)據(jù)切換到另一個數(shù)據(jù)節(jié)點，新數(shù)據(jù)節(jié)點在做數(shù)據(jù)的過程中是沒有影響的，因為業(yè)務(wù)的請求還是訪問老的實例節(jié)點，但是在最后一步路由切換，是在擴容流程里唯一會對業(yè)務(wù)有影響的，因此TDSQL對這個流程做了保護——可以自主選擇切換模式，就是可以手動切換或者自動切換。手動切換業(yè)務(wù)可以實時觀察，有問題可以及時反饋；路由切換可能要經(jīng)過幾個步驟，中間流程如果有失敗會自動回滾，不對業(yè)務(wù)有什么影響，所以也是對擴容的保護。

備份：不需要干預(yù)，TDSQL會自動備份，備份過程中也有互斥檢測。最后也會有加鎖機制，雖然比較短，但是有業(yè)務(wù)請求比較長的也會加鎖失敗，這里加鎖時間如果超過一定時間會自動停止備份，備份會擇機再次發(fā)起，不對業(yè)務(wù)有影響。也就是說，備份不影響備機的正常運行。

總結(jié)來說，TDSQL對自動化運營提供了很多安全性保障措施，保證每一個流程在關(guān)鍵節(jié)點，特別是在流程里可能會對業(yè)務(wù)的請求、訪問有影響的環(huán)節(jié)，都做了很多的保障。這個也是TDSQL運營這么長時間各種經(jīng)驗的總結(jié)，和不斷優(yōu)化的結(jié)果，所以大家可以放心使用。

TDSQL智能化故障分析平臺

下面我們進入第三章節(jié)：TDSQL故障分析自動化。

剛才我們分析到，DBA日常遇到的第二類問題主要是發(fā)現(xiàn)問題的時候如何定位分析。

3.1 TDSQL “扁鵲”如何幫助DBA提升故障定位能力

DBA在面對故障的時候往往非常煩躁，各種問題非常多。大家在定位問題的時候歸根結(jié)底有幾個難點：第一個是DBA的經(jīng)驗?zāi)芰栴}定位影響非常大，很多優(yōu)秀的DBA都是通過不斷的故障積累經(jīng)驗才能成為優(yōu)秀的DBA。第二個，我們定位的時候往往要通過各種認證登錄后臺，查看各種指標(biāo)綜合分析，這樣效率非常低。其實很多的問題都是重復(fù)發(fā)生、重復(fù)發(fā)現(xiàn)，但是我們要重復(fù)定位和解決。

所以我們希望通過“扁鵲”平臺把DBA故障分析經(jīng)驗沉淀下來，沉淀到赤兔智能運營平臺，讓它來自動分析、發(fā)現(xiàn)這些問題，為數(shù)據(jù)庫用戶和DBA帶來高效便捷的體驗。如果有新的思路、新的問題出現(xiàn)包括新的原因，我們都會持續(xù)沉淀到這個平臺來做循環(huán)，這個平臺會逐漸變得非常強大。

3.2 TDSQL故障自動化分析平臺“扁鵲”

扁鵲主要有四個主要功能：可用性分析、可靠性分析、性能分析和其他分析，其他分析也是在不斷強化?？捎梅治鲋饕獓@主備切換場景展開；可靠性分析主要以較大范圍場景的體檢報告來分析數(shù)據(jù)庫目前的問題，可以對DB狀態(tài)進行了如指掌的分析。

性能分析針對的場景就是數(shù)據(jù)庫運行變慢了。我們可以大概總結(jié)為這幾類，比如熱點表、大事務(wù)、鎖等待、長事務(wù)等，下面一層可以分析SQL事務(wù)時耗，包括對SQL的檢查優(yōu)化等，來看SQL有沒有問題。

下面這一層就依賴數(shù)據(jù)層，上面的模塊是數(shù)據(jù)的采集方式，最下面是數(shù)據(jù)的存儲方式，比如審計日志對TDSQL的數(shù)據(jù)都有采集，而DB的狀態(tài)包括DB的快照、事務(wù)信息、隱藏狀態(tài)等；同步信息包括表結(jié)構(gòu)信息等，例如表結(jié)構(gòu)不合理要先摘出來看看哪不合理。

還有是負責(zé)監(jiān)控DB的模塊，包括赤兔前臺能看到的各種指標(biāo)都在里面，還可以看到慢查詢、主備切換的流程等，包括切換成功與否、切換點，切換時間點等關(guān)鍵指標(biāo)。

右下角就是操作系統(tǒng)狀態(tài)，包括IO內(nèi)存、CPU等的狀態(tài)。

這張圖從上往下看，首先是可以分析可用性由哪些原因造成，然后有個邏輯分析層。最后是新增數(shù)據(jù)接入層。通過這個圖大家可以直觀了解到扁鵲工作方式以及內(nèi)部邏輯。

接下來針對扁鵲的三大功能舉例看一下它怎么做故障分析。

3.3 扁鵲數(shù)據(jù)庫智能分析平臺之DB可用性分析

TDSQL分布式數(shù)據(jù)庫通常是一主兩備的架構(gòu)，TDSQL的Agent會周期性地對DB做探活。探活是指模擬用戶的請求，建立TCP連接后然后執(zhí)行查詢和寫入，比如監(jiān)控表的查詢，模擬用戶的請求看是否正常。TDSQL的可用性在于探活異常，如果認為DB發(fā)生異常，就會自動發(fā)起切換流程。

這是一個自動化流程，但是切完之后我們要看一下為什么引發(fā)了這次切換。這個可歸結(jié)為為什么切換時間點發(fā)生了探活失敗。

可用性問題歸結(jié)為主DB Agent探活失敗，大致可以分為三類：磁盤故障、DB重啟和資源耗盡。我們分別看這三類故障的原因：

• 磁盤故障運行時間長會有故障，我們要分析日志信息來看磁盤在主備切換的時間點以及切換有沒有發(fā)生異常。一可以通過分析IO性能來判斷——磁盤在故障特別是SSD性能耗盡的時候會導(dǎo)致IO異常，IO非常高但是讀寫性非常差，每秒都執(zhí)行不了幾次讀寫，而且服務(wù)響應(yīng)時間非常長。
• DB重啟依托于實時上報DB啟動時間。只要啟動時間發(fā)生變化我們認為DB發(fā)生了重啟，這個也可作為DB重啟故障原因。
• 資源耗盡這一類故障分析中，磁盤IO分析和剛才的IO是有區(qū)別的，磁盤故障IO是因為磁盤故障，由正常請求引起，這個可能是因為做了大的更新查詢；此外還包括線程池狀態(tài)和大事務(wù)狀態(tài)等場景分析。

3.3.1 DB可用性分析：大事務(wù)問題

接下來看大事務(wù)引起的可用性分析問題。

我們分析主DB的請求，剛才提到了有Agent負責(zé)探活心跳周期性，同時也會有業(yè)務(wù)的請求——假設(shè)這個地方一個大表刪除了1000W行……這些問題TDSQL結(jié)合成一個組提交。提交后可想而知會產(chǎn)生很大的binlog，據(jù)我們了解的可能會產(chǎn)生5G、10G甚至幾十G。因為一個事務(wù)必須在一個binlog里，所以非常大的binlog。產(chǎn)生大的binlog又會產(chǎn)生哪些因素呢？整個流程下來會發(fā)現(xiàn)耗時非常長。而探活的時候會有時間頻率限制，超過時間就會認為失敗，探活失敗提交了一分鐘必然會發(fā)生主備切換，因為可能很多心跳已經(jīng)上報仲裁主DB已經(jīng)故障。

我們通過分析可以看這種故障類型有幾個特征：心跳寫入超時、產(chǎn)生大binlog文件、Innodb影響行數(shù)突增，以及事務(wù)處理prepared狀態(tài)。

通過提取出的這四個特征——四個特征都是符合的，我們可以認為是由大事務(wù)引起的，從而導(dǎo)致切換。TDSQL自動運營平臺針對主備切換的故障流程做分析，可以一鍵分析生成一個分析報告。

3.4 DB性能分析

接下來講一下DB性能分析。

非常直觀就是執(zhí)行慢。我們可以根據(jù)經(jīng)驗大概分成四類，網(wǎng)絡(luò)問題、TDSQL本身問題、資源性問題和鎖。網(wǎng)絡(luò)問題比較容易理解，網(wǎng)卡流量、網(wǎng)絡(luò)波動性；SQL問題包括索引分析、SQL分析；系統(tǒng)資源比如CPU、IO、Swap活躍度和鎖等待的問題。需要分析的內(nèi)容也是依托于采集數(shù)據(jù)來完成操作。

3.4.1 DB性能智能分析：鎖等待

接下來看鎖等待引起的DB性能問題設(shè)計思路。

右邊這個看似有兩個對話，這是典型的鎖沖突對話：首先是begin開啟事務(wù)。在第一秒的時候會話1開始更新，在第二秒的時候會話2也要更新。又過了一段時間對話1完成了——鎖可能停留在兩個時間點，這個時間點極有可能出現(xiàn)的情況是DB處于鎖的狀態(tài)。這里簡單舉了兩個會話，幾千個同時在等待某人執(zhí)行SQL的時候給鎖住了，現(xiàn)場DB分析的話，可能會經(jīng)歷這樣一個流程：

第二個時間點，會話已經(jīng)提交了，會話2時間比較久，在提交的一瞬間SQL就執(zhí)行成功了。會話2整個已經(jīng)超時，時間點二業(yè)務(wù)場景下1個小時之前會話超時了，趕緊看一下當(dāng)時是什么情況。時間點1非常簡單，熟悉DB的比較了解這種方法，底下有表就是事務(wù)表、鎖等待表，通過關(guān)系我們可以查出來會話1沒有提交，把會話2給堵塞了，所以這種場景最容易分析。平常做把三個表的關(guān)系記錄一下去查詢，看看到底是哪個會話有問題然后把會話1殺掉，在業(yè)務(wù)看一下是不是有問題。

而如果在赤兔平臺，這些可以一鍵完成，在赤兔上點“實時分析”可以看到現(xiàn)場案例是什么，我們有建議把會話殺掉然后可以恢復(fù)正常，當(dāng)然這個之后要找業(yè)務(wù)看一下事務(wù)為什么這么長時間而不釋放。

第二個場景，會話1已經(jīng)提交了，事后分析沒有故障現(xiàn)場怎么辦？我們可以看一下這邊的故障特征，這類的故障特征是會話2更新的表超時了，或者結(jié)余時間比較久。它的時間超時在T1，或者很久在T1執(zhí)行完了都有可能。

我們的目標(biāo)是找出來會話X，到底是哪個會話把會話2堵塞了，首先會話X在時間點是持有T表的行鎖，只有它具備這個條件才有可能把會話2堵塞住。我們可以通過SQL日志分析怎么把會話找出來。剛才提到了SQL有所有信息，其中就是客戶端IP，由于SQL日志有很多請求是交錯在一起的，比如開啟一條事務(wù)執(zhí)行一條SQL，又開始另外一條執(zhí)行SQL，是很多事務(wù)連接的請求交錯在一起的，我們很難分析出來一個事務(wù)的關(guān)系。所以我們第一步要做的是先要根據(jù)客戶端的ip port聚合還原事物，按照維度做聚合然后可以知道ip port所有的執(zhí)行數(shù)據(jù)。我們會對SQL進行依法解析然后提交時間。

另外，我們還想提取事務(wù)中間可能有各種查詢更新操作，這些SQL到底是持有哪個表的鎖，它沒有鎖的話肯定對會話2沒有影響。緊接著我們得出這樣的結(jié)論：首先是事務(wù)的執(zhí)行時間，什么時候開始、什么時候結(jié)束。事務(wù)的持鎖列表有沒有可能造成會話2的鎖堵塞，還有SQL的間隔時間，這個也是幫助業(yè)務(wù)去看兩個事務(wù)之間間隔這么長時間，中間到底發(fā)生了什么把會話2鎖了，是否合理。

還有SQL的耗時，這里面也包括每個SQL的耗時，有個SQL執(zhí)行時間非常長，確實把會話2鎖了，我們要找出來看看為什么執(zhí)行時間這么長。

通過這些信息表T1時間點可以得出來是由會話X對會話2造成的鎖定，然后再看會話X為什么要執(zhí)行得不合理，至少看一下業(yè)務(wù)是否正常。我們再看一個案例，在時間點包括鎖來看是哪個會話引起了鎖的等待，然后我們會看間隔時間包括信息，用來定位的會話引起了鎖等待。

3.4.2 DB可靠性智能分析

DB可用性分析，是指對數(shù)據(jù)庫的狀態(tài)可以提前了解，包括：系統(tǒng)狀態(tài)、表空間分布、索引、死鎖診斷、鎖等待診斷、慢查詢分析、DB狀態(tài)檢查等等。我們可以看到這樣的案例：數(shù)據(jù)庫評分非常低，做了分析之后看到它是哪些問題——CPU空間過度？任務(wù)非常多？下面的狀態(tài)信息都可以幫助大家來看DB到底有沒有問題，是否可以提前發(fā)現(xiàn)問題并解決。

平時對重要DB覺得運營狀態(tài)不太了解就可以做一次診斷。當(dāng)然這個系統(tǒng)也可以做自動診斷，也支持每天針對重要DB每天出一個預(yù)報。這個是DB的可靠性分析介紹。

總結(jié)

今天主要分享了幾部分內(nèi)容：

總結(jié)而言，TDSQL自動化運營體系可以幫助大家把日常中非常煩瑣、需要手動操作的事情進行標(biāo)準(zhǔn)化、自動化、智能化，一鍵完成，減輕大家的負擔(dān)。因為我們做了標(biāo)準(zhǔn)化沉淀，很多需求不需要DBA自己做，基于TDSQL運營平臺，業(yè)務(wù)也可以直接解決。日常的一些操作可以通過赤兔的權(quán)限管理放開給業(yè)務(wù)。

今天的內(nèi)容大概就介紹到這里，謝謝大家。

Q&A

Q：是否有多活機制？

A：我們有多活機制，并且有強同步復(fù)制機制，保證數(shù)據(jù)一致。。

Q：online ddl是否保持兩個數(shù)據(jù)一致？

A：online ddl是基于工具進行改造。簡單而言就是會實時把更新類操作寫進新表，然后分批把原本的數(shù)據(jù)覆蓋到新表里。數(shù)據(jù)覆蓋完之后兩個表的數(shù)據(jù)一致，觸發(fā)器可以把業(yè)務(wù)請求的數(shù)據(jù)實時同步，直到切表流程結(jié)束。

Q：對于大事務(wù)如果剛開始執(zhí)行沒有注意到等過了十分鐘才發(fā)現(xiàn)事務(wù)沒有執(zhí)行完，這個時候可以做哪些處理？

A：如果終止會話事務(wù)也會持續(xù)比較長的時間，如果一直等事務(wù)持續(xù)也是一個比較長的時間。這個時候我建議把它殺掉，如果不放心，剛才提到的有大事務(wù)極有可能觸發(fā)主備切換。我們會強制做切換來保證高可用。

Q：死鎖檢測是通過定位嗎？

A：這里不是死鎖，是鎖等待，是兩個事務(wù)都無法執(zhí)行，我們剛才的例子是可以提交，只是長時間未提交的事務(wù)。會話2一直在等，在某個時間點超時了，這個時間點2之前肯定是有會話把表鎖住了，我們的目標(biāo)是要找出來在會話2之前某個時間點的某個會話是否持有表的鎖。我們根據(jù)表信息和時間點通過引擎日志，這個日志里記錄了所有用戶SQL執(zhí)行信息，可以通過這個表的信息來分析鎖超時的前后，主要是前有沒有會話持有。當(dāng)然這是一個篩選的過程，在那個時間點會有多個會話，這個會話就是做一個篩選，然后看會話是否合理。因為沒有DB故障現(xiàn)場只能通過發(fā)生的事務(wù)信息來看。

往期推薦

直播回顧 | 隨意遷移，無損遷移，其實很簡單

特惠體驗云數(shù)據(jù)庫

當(dāng)前文章：直播回顧|數(shù)據(jù)庫運維不再難，數(shù)據(jù)庫“自動駕駛”技術(shù)已到來-創(chuàng)新互聯(lián)
標(biāo)題URL：http://muchs.cn/article42/dddeec.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供響應(yīng)式網(wǎng)站、自適應(yīng)網(wǎng)站、網(wǎng)站營銷、微信公眾號、建站公司、App開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)