溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
騰訊云數據庫國產數據庫專題線上技術沙龍正在火熱進行中，3月26日郝志剛的分享已經結束，沒來得及參與的小伙伴不用擔心，以下就是直播的視頻和文字回顧。
關注“騰訊云數據庫”公眾號，回復“0326郝志剛”，即可下載直播分享PPT。
瞬間從億條SQL中找到問題所在：TDSQL自動化運營體系_騰訊視頻
“赤兔”平臺是TDSQL提供的產品服務之一，它從管理員視角提供TDSQL的全部運維功能和上百項數據庫狀態監控指標的展示，讓數據庫管理員日常90%以上的操作均可通過界面化完成，同時更方便定位排查問題。
扁鵲系統是TDSQL面向云市場推出的一款針對數據庫性能/故障等問題的自動化分析并為用戶提供優化/解決方案的產品，它提供包括數據采集、實時檢測、自動處理、性能檢測與健康評估、SQL性能分析、業務診斷等多種智能工具的集合。
在數據庫日常應用中，常常會面對如存儲容量和性能需求急速增長帶來的性能等異常問題。對于引起數據庫異常的問題SQL，這時扁鵲可以通過一鍵診斷分析，幫助用戶快速進行智能檢測和分析，快速將問題定位，同時給出優化建議。在扁鵲的幫助下，DBA可以從日常繁雜的數據庫運維工作中解脫出來。在支持騰訊會議需求量暴漲，數據庫遇到性能問題過程中，扁鵲智能運維曾幫助DBA快速在億條SQL中定位到了問題SQL，并提供優化意見，將數據庫的性能問題及時扼殺在萌芽當中。系統顯示，經過優化，99%的SQL都消除了性能瓶頸。
“扁鵲”在迭代演進過程中沉淀了騰訊數據庫實踐中積累的海量運維規則知識庫，可幫助DBA迅速排查日常常見異常，而結合騰訊云海量數據+機器學習能力，扁鵲可對未知問題進行主動分析檢測，并告知客戶，盡可能將大部分異常在發生之前就發出預警，將風險降到最低，提升DB持續可靠地服務各種不同業務場景的特性能力。
“赤兔”和“扁鵲”這一套組合拳既滿足高星級業務的精細化運維，又能輕松應對大量的普通數據庫運維需求，更好地幫助用戶降低運維成本。
大家好，我是騰訊云TDSQL高級DBA郝志剛。今天分享的主題是TDSQL自動化運營體系。聽過我們前面系列課程的同學應該對TDSQL的架構原理等有比較詳細的了解。而回到現實的工作中處理各種問題，還是要埋頭解決各種運營問題。所以今天我們介紹一下TDSQL的自動化運營體系，看TDSQL自動化運營體系能為廣大DBA或者運維人員帶來什么。事實上TDSQL自動化運營體系可以幫助DBA的工作更放松一點、輕松一點，而不是想象中比較苦、比較累的工作，希望對大家有幫助。
我演講分為四個章節：
第一個章節是TDSQL自動化運營體系，包括架構、支持的功能特性等。第二、第三章會基于DBA的兩大事務體系——日常處理的事務，以及故障分析類事務，結合一些典型案例來介紹TDSQL自動化運營體系是如何幫助大家高效、便捷、自動化地解決這些事務問題的。第四章做簡單的總結。
第一章節主要括三部分內容，一方面是對DBA日常工作進行梳理。第二介紹TDSQL自動化運營平臺“赤兔”。第三介紹數據庫后臺如何實現自動化運營，介紹背后原理性的東西，幫助大家理解TDSQL是如何怎么實現自動化運營的。
大家看到這個圖會非常煩躁，這是日常DBA要處理各種問題：比如一個業務要上線，需要創造一個實例；比如機器要擴容，需要緊急申請權限；不小心弄錯數據，需要趕緊回檔；或者是表結構需要變更………這張圖里就是DBA日常要面臨的復雜量大的問題處理。從中我們也可以總結出兩個特點：第一個每個DBA對于處理這些都會有一套自己的邏輯。比如我做一個DDL，可能這個DDL可以這么操作，另外一個DDL要用另外一個工具，這些操作的方法不夠標準而且不夠穩定；也許今天用的這個方法明天用就不靈了——它的穩定性難以保證。
第二，我們做這個事情需要很多后臺操作來配合，后臺操作對于DBA來說非常頻繁。一方面可能習慣于這種操作，但是這個方式帶來的風險會比較大，我們敲下一條命令的時候有沒有感覺很心慌，它的后果是什么？以往沒有統一的平臺來保證做這個事情是非常安全的。
所以TDSQL致力于解決這兩個難點：
第一個是流程要標準化；
另一方面是效率提升。
我們不需要后臺操作，而是前臺點一點就可以解決DBA的大部分事務。
DBA日常工作大致可以分為兩類：一類是日常類事務，另一類是故障類事務。日常類就是平時業務的各種需求，DBA通過一些腳本、自動化工具可以做的事情；故障類就是比如我們遇到一個難題，“數據庫連不上”，“數據庫特別慢”，需要看一下為什么。
我們簡單看一下日常類。除了剛才提到的創建實例、DDL在線變更，還有實例下線，這個雖然不常用，但是數據庫運營較長一段時間中也是可能遇到的。此外還包括業務停運了將數據庫清掉然后存放其他數據，還有參數調整和調優——我覺得這個超時時間可能設得不太合理，業務側要這么設置更改，等等。而擴容更是在所難免——業務數據量特別大，或者請求量特別多，實例撐不住了就要擴容。還有讀寫分離，還有重做備機、備份手工切換、在線SQL……
故障類指的是問題診斷類型：業務說DB連不上，幫忙看一下為什么；還有監控預警——如果DB有異常我們要自動發現這個問題，不然非常被動。系統分析——可能數據庫運行慢了，但是還不影響使用性，看一下能不能有優化的空間；自動容災切換就是保證用戶的高可用；數據回檔防止數據誤刪；日常巡檢是針對性地發現一些潛在問題。
以上大概介紹了一些事務，但是這些并不是說完全代表TDSQL自動化運營平臺支持的功能，這只是簡單列舉了幾個比較重要的案例。言歸正傳，這些事情TDSQL是怎么自動化完成的？TDSQL把這些功能呈現在數據庫運營平臺“赤兔”上，所有用戶包括DBA，在赤兔上就可以完成以上所有的操作，而且全是自動化的；赤兔又會和TDSQL打通，赤兔會把流程以任務的形式發給TDSQL，TDSQL集群會自動幫用戶完成這個事情，并且反饋給赤兔，然后用戶就可以看到這個操作的結果。
所以赤兔平臺整個流程就是把每一項日常類事務、故障分析類事務封裝成一個個自動化流程，然后打通用戶的需求和TDSQL后臺操作的流程，幫助大家能夠利用平臺高效安全地解決日常工作中遇到的問題。
接下來介紹TDSQL后臺如何完成自動化流程處理，包括介紹其中的自動化處理流程以及核心的模塊。
這個圖如果大家聽過前面一系列的分享應該是有所了解，但是今天這個圖和之前的架構圖稍微有一點不一樣，我們依次看一下：
用戶的請求在赤兔平臺以任務的形式發給后臺的OSS（OSS是TDSQL對外的接口），OSS又會做一個分發，把一部分的任務寫在MetaCluster里面。MetaCluster寫成任務之后左邊有scheduler和onlineddl兩個模塊會監控監聽各自的任務節點，有新的任務就進行處理。
OSS把問題分析類型的任務會直接發到扁鵲——TDSQL自動化運營體系中的智能分析平臺。扁鵲負責問題智能分析，它利用監控采集的數據——比如DBA的狀態、主備切換等TDSQL監控數據，以及扁鵲還會實際訪問數據節點，采集它認為需要支撐分析實例的數據。扁鵲在TDQSL框架里是一個新的模塊。另外還有一個模塊是onlineddl，它專門獨立處理DDL請求。除了這兩種請求類型，其他的任務基本由scheduler模塊完成。
右下角有一條線是Agent——每個節點都由Agent進程模塊來監控甚至完成輔助性動作，scheduler無法直接接觸所以Agent也會輔助完成剛才提到的流程。它也是通過MetaCluster獲取自己需要的信息進行處理，處理完之后響應反饋給scheduler甚至其他模塊。
所以這個圖有三個核心模塊來處理日常的流程：一個是扁鵲，這個是問題分析模塊。onlineddl處理DDL請求，以及TDSQL各個模塊后面的角色以及任務的處理。TDSQL自動化運營流程和框架就介紹到這里。
接下來講第二章，TDSQL日常事物處理自動化。
剛才講過我們把DBA任務分成兩類，一類是日常類，一類是故障類。先講日常類的處理自動化，這個章節會選取兩個日常非常常見的場景分析，分享TDSQL是如何解決這些問題的。
第一是重做DB節點功能，第二個是在線DDL功能，第三是TDSQL在自動化流程里如何做安全保障。
第一節重做DB節點。大家可能會想為什么重做DB節點？這個場景比較常見，雖然它不是每天都發生，但是它隔一段時間就會發生，而且這個事情也是比較重要的。比如機器故障了機器修復可能需要一點時間，機器修復之后需要重新加入集群，數據可能就丟失；或者數據非常舊，已經追不上了，我們需要對這個數據節點進行重做；另外，如果卡頓無法恢復了我們就需要對數據節點進行重做，恢復節點的功能。
這個怎么做呢？我們可以看到這樣一張圖：
首先系統會發起重做流程——這個流程在赤兔上進行完成，赤兔會把任務發給TDSQL集群。TDSQL集群針對這個任務有四個步驟：
1. 為什么要重做DB節點呢？因為機器上可能殘留一些數據，我們需要清掉，刪除限速。2. 拉取鏡像。無論是邏輯上還是物理上，都需要拉過來到節點上，作為數據的基準。3. 然后是加載鏡像。4. 最后是恢復同步。
可能大家在日常的運維或者是處理事情的時候都是這個流程，它基本比較符合大家的習慣。不同的是可能以往較多的是手工處理，而赤兔在這里一鍵就可以發下去。
整個流程做了非常好的優化：
赤兔提供了主節點保護，因為假如是1主2備架構，為了防止出錯，系統限制了不能直接在主節點實施重做。此外還形成了實時節點信息，例如這個節點是不是故障狀態？延遲多少？……通過這個優化我們可以實時判斷是不是正確的節點。
再看重裝DB步驟。第一步會刪除限速，而且這個數據往往是非常大的，幾百G甚至上T，所以我們要控制速度，如果快速刪除會導致IO較高，而且一臺機器上是多租戶的架構，可能會影響其他實例的正常運行，所以要限速刪除。另一方面，刪除之后要把數據進程重新安裝，安裝的時候會自動拉取DB參數。因為DB在運行過程中可能很多參數已經被改動，安裝之后的參數要保持和原來的參數一致，所以安裝過程要自動拉取。而且，有時候參數列表會很長有十幾個，手動操作是一個容易失誤且工作量極大的事情。
另外，拉取鏡像步驟，這是耗時最長而且是比較重要的一步，這里面做了三個優化：第一是選擇最優的數據源，比如像一主幾備的情況下，每個備機都有延遲狀況，我們可能會選擇延遲最小的，這個數據是最新的，如果是一備的情況則優先選擇備機。而這個過程可能會對業務的讀寫有影響，所以要選擇最優的數據。第二拉取進程——比如同時做了很多流程不能同時拉取，一個是網卡流量會跑滿，另外是由于有大量數據寫入，就是IO負載比較重。所以要互斥，這樣影響是最小的。第三是做壓縮加速——這個地方主要是在于數據源，系統會把數據拉取的鏡像進行優化壓縮，壓縮之后傳到做的節點上；這樣做的好處一方面是減輕網絡的壓力，壓縮比大約是三分之一到四分之一。同時，我們可以加速，畢竟傳輸比較小，比如壓縮四分之一傳100兆就是傳過去400兆的數據，對提升效率非常有幫助。
最后步驟是建立同步，這里主要是確認同步點以及恢復同步，這里TDSQL會幫助你自動去做。
所以大家看到，整個流程對用戶來說只需要在赤兔上點擊“發起重做”就可以自動完成整個流程，不需要過度介入。
我們來看一個重做DB的例子。
上面的圖是一個實錄：可以看到DB節點有三個，重做節點就在右下角，點“重做備機”按鈕進入流程，這個頁面可以實時顯示兩個備節點狀態，我們可以看到第一個備節點延遲非常大，這個就是我們需要重做的異常節點，防止大家誤操作選錯節點。提交完之后過一段時間會告訴你“重做成功”。整個流程就結束了。
我們再看在線DDL功能。
操作DDL非常常見的應用，尤其是在業務變化非常頻繁、表結構頻繁變化的場景中。為什么要提在線DDL？如果是面對一個普通的小表，那么可以直接做DDL，但是如果面對的是一個數據量比較大的表，比如幾十G甚至幾百G，要做一個表結構變更怎么辦？這個時候很有可能影響業務請求，所以我們提出要做在線DDL。
在赤兔上，在線DDL也非常簡單：我們在赤兔上提交請求，然后傳輸到TDSQL模塊實施，一共兩步—熟悉數據庫的應該比較了解，這兩個步驟一個負責拷貝數據，隨后表數據同步完之后再進行切表——新老表進行切換。
TDSQL在這個流程里做了哪些事情？赤兔可以自定義DDL的開始時間。那為什么要做這個事情？DDL雖然是在線，但是也會涉及到拷貝數據，特別是在業務負載比較高的時候會對業務有影響，我們希望在業務不繁忙的時候——業務一天里的周期一般是固定的，即在業務低谷的時候做這個事情，因此平臺支持可以自定義時間，比如白天發起任務，晚上一點鐘業務低估時再正式運行任務。
拷貝數據。剛才提了拷貝數據可能會對業務有時耗影響，所以TDSQL會檢測這兩個指標：備機延遲檢測與活躍鏈接檢測——超過了會暫停，直到恢復正常時再繼續。這兩個指標在前臺也可以自定義，不過系統有推薦的默認值，一般不需要更改。
另外是切表流程。這個流程涉及到新老表的切換——把新表切成老表的名字。
切表流程涉及兩個功能應用：切表加鎖檢測和保護，以及切表模式自由選擇。第一個，日常中我們很常見的場景是，切表前有一個大的事務在訪問這張表，查詢了半個小時還沒有跑出來。這個時候要做切表操作就獲取不到元數據鎖，同時又阻塞了后面的業務請求，后面的業務請求會等前面的切表流程才能繼續。所以TDSQL根據這個場景做了一個切表加鎖保護——就是說，我們在知道要切表之前，要先看一下請求里有沒有這表的大查詢，有的話就暫時不切，先讓它完成，我們不會把它直接殺掉。開始切的話時間非常短，對用戶最多影響一秒鐘。如果正要發生切表時，正好有個請求搶在前面讓切表無法執行，那系統就自動超時，不影響后面的業務SQL。回到數據同步狀態隔一段時間又會發起切表，而且間隔時間會越來越長，直到可以完成整個DDL操作。
另一個自由選擇功能意味著，切表模式可以選擇手動和自動切表：自動完成也有加鎖保護；手動切表就是拷貝數據完成之后不立即切表，而是DBA可以手工在前臺發起切表操作。
我們看一個在線DDL的例子：
左圖就是在線DDL頁面，通過頁面可以看到表結構，大家點擊“編輯”按鈕就可以修改字段和索引。右圖的頁面里面我們可以看到，剛才提到的參數設置都可以自定義，也可以選擇默認值，點擊“確認”后整個過程自動完成。如果選擇手動切表，可以選擇合適的時間完成切表操作。
我們看一下安全保護機制，流程自動化了，我們更要保證這里面每一個流程都是安全合理的。
安全性保障不僅限于這些，PPT里選取了部分常見的場景。
權限申請非常常見：如果有用戶已申請了密碼A，而且程序已經使用這個賬戶在運行中，如果再申請這個用戶而使用不同密碼，系統會自動檢查，所以不讓老的密碼被覆蓋掉。
第二類是onlineddl自動保護。
第三個是實例下線，這個我們做了一個隔離定時刪除功能。我們可以先進行隔離，隔離之后訪問數據庫的請求都會被拒掉，但是隔離狀態是可以及時恢復的，所以我們相當于放在一個回收站里，數據還沒有清掉，但業務訪問不了。過一段時間定時清理，比如7天之后（這個時間長度是可以自定義的）沒有業務反饋，則可以清掉，安全下線。
重做DB節點，在這個環節TDSQL提供了主節點保護的功能機制。擴容，會涉及到TDSQL擴容：把數據切換到另一個數據節點，新數據節點在做數據的過程中是沒有影響的，因為業務的請求還是訪問老的實例節點，但是在最后一步路由切換，是在擴容流程里唯一會對業務有影響的，因此TDSQL對這個流程做了保護——可以自主選擇切換模式，就是可以手動切換或者自動切換。手動切換業務可以實時觀察，有問題可以及時反饋；路由切換可能要經過幾個步驟，中間流程如果有失敗會自動回滾，不對業務有什么影響，所以也是對擴容的保護。
備份：不需要干預，TDSQL會自動備份，備份過程中也有互斥檢測。最后也會有加鎖機制，雖然比較短，但是有業務請求比較長的也會加鎖失敗，這里加鎖時間如果超過一定時間會自動停止備份，備份會擇機再次發起，不對業務有影響。也就是說，備份不影響備機的正常運行。
總結來說，TDSQL對自動化運營提供了很多安全性保障措施，保證每一個流程在關鍵節點，特別是在流程里可能會對業務的請求、訪問有影響的環節，都做了很多的保障。這個也是TDSQL運營這么長時間各種經驗的總結，和不斷優化的結果，所以大家可以放心使用。
下面我們進入第三章節：TDSQL故障分析自動化。
剛才我們分析到，DBA日常遇到的第二類問題主要是發現問題的時候如何定位分析。
DBA在面對故障的時候往往非常煩躁，各種問題非常多。大家在定位問題的時候歸根結底有幾個難點：第一個是DBA的經驗能力對問題定位影響非常大，很多優秀的DBA都是通過不斷的故障積累經驗才能成為優秀的DBA。第二個，我們定位的時候往往要通過各種認證登錄后臺，查看各種指標綜合分析，這樣效率非常低。其實很多的問題都是重復發生、重復發現，但是我們要重復定位和解決。
所以我們希望通過“扁鵲”平臺把DBA故障分析經驗沉淀下來，沉淀到赤兔智能運營平臺，讓它來自動分析、發現這些問題，為數據庫用戶和DBA帶來高效便捷的體驗。如果有新的思路、新的問題出現包括新的原因，我們都會持續沉淀到這個平臺來做循環，這個平臺會逐漸變得非常強大。
扁鵲主要有四個主要功能：可用性分析、可靠性分析、性能分析和其他分析，其他分析也是在不斷強化。可用分析主要圍繞主備切換場景展開；可靠性分析主要以較大范圍場景的體檢報告來分析數據庫目前的問題，可以對DB狀態進行了如指掌的分析。
性能分析針對的場景就是數據庫運行變慢了。我們可以大概總結為這幾類，比如熱點表、大事務、鎖等待、長事務等，下面一層可以分析SQL事務時耗，包括對SQL的檢查優化等，來看SQL有沒有問題。
下面這一層就依賴數據層，上面的模塊是數據的采集方式，最下面是數據的存儲方式，比如審計日志對TDSQL的數據都有采集，而DB的狀態包括DB的快照、事務信息、隱藏狀態等；同步信息包括表結構信息等，例如表結構不合理要先摘出來看看哪不合理。
還有是負責監控DB的模塊，包括赤兔前臺能看到的各種指標都在里面，還可以看到慢查詢、主備切換的流程等，包括切換成功與否、切換點，切換時間點等關鍵指標。
右下角就是操作系統狀態，包括IO內存、CPU等的狀態。
這張圖從上往下看，首先是可以分析可用性由哪些原因造成，然后有個邏輯分析層。最后是新增數據接入層。通過這個圖大家可以直觀了解到扁鵲工作方式以及內部邏輯。
接下來針對扁鵲的三大功能舉例看一下它怎么做故障分析。
TDSQL分布式數據庫通常是一主兩備的架構，TDSQL的Agent會周期性地對DB做探活。探活是指模擬用戶的請求，建立TCP連接后然后執行查詢和寫入，比如監控表的查詢，模擬用戶的請求看是否正常。TDSQL的可用性在于探活異常，如果認為DB發生異常，就會自動發起切換流程。
這是一個自動化流程，但是切完之后我們要看一下為什么引發了這次切換。這個可歸結為為什么切換時間點發生了探活失敗。
可用性問題歸結為主DB Agent探活失敗，大致可以分為三類：磁盤故障、DB重啟和資源耗盡。我們分別看這三類故障的原因：
接下來看大事務引起的可用性分析問題。
我們分析主DB的請求，剛才提到了有Agent負責探活心跳周期性，同時也會有業務的請求——假設這個地方一個大表刪除了1000W行……這些問題TDSQL結合成一個組提交。提交后可想而知會產生很大的binlog，據我們了解的可能會產生5G、10G甚至幾十G。因為一個事務必須在一個binlog里，所以非常大的binlog。產生大的binlog又會產生哪些因素呢？整個流程下來會發現耗時非常長。而探活的時候會有時間頻率限制，超過時間就會認為失敗，探活失敗提交了一分鐘必然會發生主備切換，因為可能很多心跳已經上報仲裁主DB已經故障。
我們通過分析可以看這種故障類型有幾個特征：心跳寫入超時、產生大binlog文件、Innodb影響行數突增，以及事務處理prepared狀態。
通過提取出的這四個特征——四個特征都是符合的，我們可以認為是由大事務引起的，從而導致切換。TDSQL自動運營平臺針對主備切換的故障流程做分析，可以一鍵分析生成一個分析報告。
接下來講一下DB性能分析。
非常直觀就是執行慢。我們可以根據經驗大概分成四類，網絡問題、TDSQL本身問題、資源性問題和鎖。網絡問題比較容易理解，網卡流量、網絡波動性；SQL問題包括索引分析、SQL分析；系統資源比如CPU、IO、Swap活躍度和鎖等待的問題。需要分析的內容也是依托于采集數據來完成操作。
接下來看鎖等待引起的DB性能問題設計思路。
右邊這個看似有兩個對話，這是典型的鎖沖突對話：首先是begin開啟事務。在第一秒的時候會話1開始更新，在第二秒的時候會話2也要更新。又過了一段時間對話1完成了——鎖可能停留在兩個時間點，這個時間點極有可能出現的情況是DB處于鎖的狀態。這里簡單舉了兩個會話，幾千個同時在等待某人執行SQL的時候給鎖住了，現場DB分析的話，可能會經歷這樣一個流程：
第二個時間點，會話已經提交了，會話2時間比較久，在提交的一瞬間SQL就執行成功了。會話2整個已經超時，時間點二業務場景下1個小時之前會話超時了，趕緊看一下當時是什么情況。時間點1非常簡單，熟悉DB的比較了解這種方法，底下有表就是事務表、鎖等待表，通過關系我們可以查出來會話1沒有提交，把會話2給堵塞了，所以這種場景最容易分析。平常做把三個表的關系記錄一下去查詢，看看到底是哪個會話有問題然后把會話1殺掉，在業務看一下是不是有問題。
而如果在赤兔平臺，這些可以一鍵完成，在赤兔上點“實時分析”可以看到現場案例是什么，我們有建議把會話殺掉然后可以恢復正常，當然這個之后要找業務看一下事務為什么這么長時間而不釋放。
第二個場景，會話1已經提交了，事后分析沒有故障現場怎么辦？我們可以看一下這邊的故障特征，這類的故障特征是會話2更新的表超時了，或者結余時間比較久。它的時間超時在T1，或者很久在T1執行完了都有可能。
我們的目標是找出來會話X，到底是哪個會話把會話2堵塞了，首先會話X在時間點是持有T表的行鎖，只有它具備這個條件才有可能把會話2堵塞住。我們可以通過SQL日志分析怎么把會話找出來。剛才提到了SQL有所有信息，其中就是客戶端IP，由于SQL日志有很多請求是交錯在一起的，比如開啟一條事務執行一條SQL，又開始另外一條執行SQL，是很多事務連接的請求交錯在一起的，我們很難分析出來一個事務的關系。所以我們第一步要做的是先要根據客戶端的ip port聚合還原事物，按照維度做聚合然后可以知道ip port所有的執行數據。我們會對SQL進行依法解析然后提交時間。
另外，我們還想提取事務中間可能有各種查詢更新操作，這些SQL到底是持有哪個表的鎖，它沒有鎖的話肯定對會話2沒有影響。緊接著我們得出這樣的結論：首先是事務的執行時間，什么時候開始、什么時候結束。事務的持鎖列表有沒有可能造成會話2的鎖堵塞，還有SQL的間隔時間，這個也是幫助業務去看兩個事務之間間隔這么長時間，中間到底發生了什么把會話2鎖了，是否合理。
還有SQL的耗時，這里面也包括每個SQL的耗時，有個SQL執行時間非常長，確實把會話2鎖了，我們要找出來看看為什么執行時間這么長。
通過這些信息表T1時間點可以得出來是由會話X對會話2造成的鎖定，然后再看會話X為什么要執行得不合理，至少看一下業務是否正常。我們再看一個案例，在時間點包括鎖來看是哪個會話引起了鎖的等待，然后我們會看間隔時間包括信息，用來定位的會話引起了鎖等待。
DB可用性分析，是指對數據庫的狀態可以提前了解，包括：系統狀態、表空間分布、索引、死鎖診斷、鎖等待診斷、慢查詢分析、DB狀態檢查等等。我們可以看到這樣的案例：數據庫評分非常低，做了分析之后看到它是哪些問題——CPU空間過度？任務非常多？下面的狀態信息都可以幫助大家來看DB到底有沒有問題，是否可以提前發現問題并解決。
平時對重要DB覺得運營狀態不太了解就可以做一次診斷。當然這個系統也可以做自動診斷，也支持每天針對重要DB每天出一個預報。這個是DB的可靠性分析介紹。
今天主要分享了幾部分內容：
總結而言，TDSQL自動化運營體系可以幫助大家把日常中非常煩瑣、需要手動操作的事情進行標準化、自動化、智能化，一鍵完成，減輕大家的負擔。因為我們做了標準化沉淀，很多需求不需要DBA自己做，基于TDSQL運營平臺，業務也可以直接解決。日常的一些操作可以通過赤兔的權限管理放開給業務。
今天的內容大概就介紹到這里，謝謝大家。
Q：是否有多活機制？
A：我們有多活機制，并且有強同步復制機制，保證數據一致。。
Q：online ddl是否保持兩個數據一致？
A：online ddl是基于工具進行改造。簡單而言就是會實時把更新類操作寫進新表，然后分批把原本的數據覆蓋到新表里。數據覆蓋完之后兩個表的數據一致，觸發器可以把業務請求的數據實時同步，直到切表流程結束。
Q：對于大事務如果剛開始執行沒有注意到等過了十分鐘才發現事務沒有執行完，這個時候可以做哪些處理？
A：如果終止會話事務也會持續比較長的時間，如果一直等事務持續也是一個比較長的時間。這個時候我建議把它殺掉，如果不放心，剛才提到的有大事務極有可能觸發主備切換。我們會強制做切換來保證高可用。
Q：死鎖檢測是通過定位嗎？
A：這里不是死鎖，是鎖等待，是兩個事務都無法執行，我們剛才的例子是可以提交，只是長時間未提交的事務。會話2一直在等，在某個時間點超時了，這個時間點2之前肯定是有會話把表鎖住了，我們的目標是要找出來在會話2之前某個時間點的某個會話是否持有表的鎖。我們根據表信息和時間點通過引擎日志，這個日志里記錄了所有用戶SQL執行信息，可以通過這個表的信息來分析鎖超時的前后，主要是前有沒有會話持有。當然這是一個篩選的過程，在那個時間點會有多個會話，這個會話就是做一個篩選，然后看會話是否合理。因為沒有DB故障現場只能通過發生的事務信息來看。
直播回顧 | 隨意遷移，無損遷移，其實很簡單
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
