溫馨提示×

溫馨提示×

您好，登錄后才能下訂單哦！

密碼登錄×

忘記密碼？

登錄注冊×

獲取短信驗證碼

其他方式登錄

點擊登錄注冊即表示同意《億速云用戶服務條款》

用戶登錄×

賬戶密碼登錄

請使用微信掃描上方二維碼

使用幫助

請求超時！

請點擊重新獲取二維碼

直播回顧 |TDSQL的交付

發布時間：2020-08-09 00:47:54 來源：ITPUB博客閱讀：243 作者：騰訊云數據庫欄目：數據庫

騰訊云數據庫國產數據庫專題線上技術沙龍正在火熱進行中，0622畢漢斌的分享已經結束，沒來得及參與的小伙伴不用擔心，以下就是直播的視頻和文字回顧。

關注“騰訊云數據庫”公眾號，回復“0622畢漢斌”，即可下載直播分享PPT

1

直播回顧：https://v.qq.com/x/page/v31023ovs5l.html

前言

整個部署過程最快僅需9 分鐘， TDSQL全球靈活部署實踐

為幫助開發者更好地了解和學習分布式數據庫技術，2020年3月，騰訊云數據庫、云加社區聯合騰訊TEG數據庫工作組特推出為期3個月的國產數據庫專題線上技術沙龍《你想了解的國產數據庫秘密，都在這！》邀請數十位鵝廠資深數據庫專家每周二和周四晚上在線深入解讀TDSQL、CDB/CynosDB、TBase三款鵝廠自研數據庫的核心架構、技術實現原理和最佳實踐等。本文將帶來直播回顧第七篇，分享TDSQL的部署實踐。

直播回顧 |TDSQL的交付

大家好，我是騰訊云TDSQL DBA畢漢斌。我們本次是圍繞著TDSQL交付的話題分享三個方面內容。包括TDSQL曾經面臨的交付要求和挑戰，以及我們開發沉淀的自動化交付方案，最后更重要的是這套質量保障體系后續可以如何繼續在交付后的用戶的全生產流程中為用戶提供全方位質量保障。

1

TDSQL交付要求和挑戰：快速給、靈活、安全給

首先我們想講的是TDSQL的交付挑戰，我們也是以三個方面去展開，第一個我們遇到的挑戰是我們TDSQL產品架構所帶來的特點：

一是產品化不斷完善帶來的特點——組件多，包括擁有數據庫內核，任務分發、冷備中心、平臺告警、性能診斷等；

二是組件之間的相互依賴的關系比較復雜。

1.1 復雜產品組件交付

直播回顧 |TDSQL的交付

首先我們從層次上把這些組件進行劃分：赤兔、監控采集、OSS、metacluster、扁鵲、onlineddl等可以劃分為一個角色，叫管理節點。我們從業務層去講的話，對業務來說，實際訪問數據庫從業務層去講的話，的過程是，先是負載均衡層，然后負載均衡層會做負載均衡到我們的到SQL引擎層，而SQL引擎層會直接訪問到我們底層的db底層DB，db上也DB上會部署agentAgent，像。圖中左側列這些我們叫做dbDB管理節點。像右側列如冷備中心、消息隊列、多源同步等，我們一般劃分為數據節點。而日志分析平臺其實就是一個其他的模塊，可劃分為其他的節點。

像這些節點之間的也是依賴關系比較復雜，像我們的管理節點之前有講到，像這些。比如管理節點，其實主要做的工作就是負責元原數據管理，像元原數據包括很多，比如以監控采集模塊為核心的監控數據，還有、以任務分發系統為核心的任務節點的數據。第二個是我們的DB模塊，DB會和管理節點有一些交付交互，首先——所有的角色不僅是除了DB節點，還有其他的節點都會向管理節點發送他的監控信息，因為都會把監控信息發送上去。而管理節點也會下發一些任務，比如說客戶在前臺進行一些的變更，比如說垂直擴容、水平擴容、主備切換，像這些的等變更動作也是會到實際的DB上進行的交付，也會到實際的DB進行交互。數據節點首先會像向管理節點發送數據，會和DB節點做一些交付互，比如我們最常用的就是數據庫數據的備份和回檔，這個就是DB的節點和數據節點進行交付。日志分析平臺也會和DB節點去交付，他分析DB節點產生的日志，具體會做一些用戶的日志分析、SQL分析，甚至會給用戶帶來一些SQL審計的功能，也會向管理節點上報他的監控信息……

所以大家再簡單看一下，其實各個組件之間的依賴關系，可以看得出來他們還是比較復雜的。其實就是因為像我們這樣比較復雜的依賴關系。他，這對于我們的交付是帶來一定的難處。在TDSQL早期我們是通過自身TDSQL產品團隊給客戶做交付。其實按照這樣的要求，這會對交付的人力帶來很大的要求，既即使是我們去的話，部署一個交付的環境也要兩天以上。

1.2 多場景交付

第二個挑戰來自于TDSQL多個場景。

直播回顧 |TDSQL的交付

TDSQL多個場景主要來源于使用TDSQL的對象是不同的，這個對象可以劃分未使用TDSQL的人群是不同的，有個人使用，也有企業使用，也有第三方平臺使用，包括個人、企業、第三方平臺。其實這些不同的對象使用TDSQL的過程中，他們的需求和場景也是不同的。以個人使用為例，個人使用TDSQL的話，他更多強調的是我想了解你的產品，學習你的產品，體驗你的產品，個人使用可能更想我能盡量的低門檻快速上手你的產品，盡量的簡單。企業使用最主要的兩個場景，一個是POC測試，另一個就是我們的和生產場景。POC測試是，關注我們的的是整個產品的性能和功能，包括高可用性、容災能力、國產化適配等。從性能和功能的出發，也會帶來不同的場景需求。生產其實我們更多關注的是整個交付、整個產品、整個集群，是否有高可用性，是否有容災能力，是否有一次性的保證。我們的平臺接入會帶來更多的挑戰，我們的平臺可能會涉及到一些國產化交付的項目，國產化其實會對我們帶來一些兼容性的問題，還會對我們的標準對接、接入帶來一些需求。

所以由于不同的對象使用我們TDSQL的產品，就會帶來不同場景的需求如何高效滿足？

我們當時想的是我們TDSQL在交付的場景下，我們是要做多個分支去適配不同的場景，還是用一個分支去適配不同的場景？當然我們是用一個分支去適配不同的場景。

1.2 TDSQlL交付質量保障：安全、合規、多層級實時掃描

直播回顧 |TDSQL的交付

第三個挑戰也是，由于時間的推移，我們負責TDSQL去交付的人產生了變化。早期我們TDSQL交付是由我們TDSQL產品研發團隊，我們、DBA同學去現場給客戶做交付。其實在我們的產品研發團隊和DBA團隊，大家都是一個團隊，團隊內由于長期的的合作協同是有是形成了標準和質量可靠，他的交付質量也是有保證的。而隨著我們TDSQL產品化，做大做強，對外推廣用戶規模不斷擴大以后，其實會產生交付人員的不同交付人員會發生變化，當然也有一部分是我們產品研發團隊直接交付。還有一部分是由我們騰訊專門的交付團隊去交付，還有是由我們騰訊內部的第三方平臺以及騰訊外部客戶自己的第三方平臺接入了TDSQL產品，他們第三方平臺負責交付。還有也是客戶自己本身去做交付。不同的交付實施方，他們的操作和使用的過程中就會帶來一些隱患，這些隱患主要體現在以下方面如果不夠標準化，則容易帶來隱患，體現在幾個方面：

第一個是安全的方面。比如說我們環境的安全，我們知道數據庫場景是一個對內存、CPU、硬盤、LOIO的等能力，都是要求比較高的場景。之前遇到的一個case，一個客戶在數據庫的場景下，他（9：22）沒有關，在壓力比較高的情況下，由于性能問題，最終在一定的場景下帶來的一些風險的問題，其實這些就是對環境的優化。其實不僅僅是這種環境優化，包括數據庫進程會讀大量的文獻，他最大的文獻數繼承的是系統用戶的最大文件數。像這些的設置，包括數據庫場景對TCP的一些內核參數的優化等這些工作都是作為潛在風險來統一考慮的。像這些優化其實是作為式一個潛在的風險去考慮的。

第二個是監控方面。對整個集群、進程、機器的監控，提到監控還有一個以及自動的拉起，有很多即機械機器級別等的故障，故障之后一個，進程快速恢復的能力，其實要考慮到完善的自動拉起的體系這些都要作為完善的體系來考慮。其他還有比如一些定時任務，比如說包括定時去清理一些日志文獻，清理一些歷史上的數據，否則磁盤就會撐滿的情況，這在生產的環境上也是風險很大的。還有我們最后是如何保障整個集群的高可用性、容災性、（10：56）能力。剛才說到的是不同的實施人可能會帶來不同的風險，其實除了實施人以外，還有發布的版本也需要控制。有的時候我們是作為第一方去交付這個產品，有的時候我們有外部的客戶，他們的平臺會交付，不管誰去交付，這個版本是否是一個歷史版本，這個版本是否會有一些歷史的問題和隱患；如何杜絕這些潛在的舊版本帶來的隱患，檢測到這些版本的漏洞等等方面，也是我們交付質量的一個挑戰都是交付質量體系中需要解決的問題。

其實我們TDSQL交付質量服務和保障就是圍繞著上述的一些各方面問題方面，實現由在不同的實施人、實施方去交付我們TDSQL的產品下，都能保證我們TDSQL的投產的質量。這是我們在做的一個事情。

1

TDSQL自動交付方案：全球靈活部署、實時巡檢，最快9分鐘

剛才也說到TDSQL的交付過程中遇到的一些挑戰，我們針對這些上述的挑戰，TDSQL沉淀出了一套TDSQL自動化交付方案。

直播回顧 |TDSQL的交付

2.1 自動化交付方案規劃

這是TDSQL自動化交付方案的架構圖：

直播回顧 |TDSQL的交付

剛才說我們TDSQL是基于一個分支去做的來實現多場景、復雜關系下的自動化交付的，其實也可以說是基于三個分支去做的。我們TDSQL內核包，當前有三個分支，是：基于CPU的多分支進行發布，當前支持X86、arm、power。其實在我們TDSQL對客戶的發布包中，一個包自動的集成了不同CPU版本的TDSQLpocketpacket，是——以ansible組件為基礎，加上了條件檢測、操作系統調優、環境依賴的解決、安全規范、兼容性問題，我們對外做的是TDSQL私有云標準的發布包。像這個包我們是，可針對于客戶不同的場景，剛才說到的不同場景和不同的環境做的適配。

直播回顧 |TDSQL的交付

TDSQL的組件我們剛才分為四個角色，如果想要快速的交付TDSQL集群，大家只要搞清楚一件事情，打個比方說就是把不同的雞蛋放到不同的籃子里。雞蛋其實就是我們說的是指這些組件，分為這四個；籃子就是我們準備的機器，可以是虛擬機，也可以是物理機。

首先首先說一下我們的個人體驗的環境，個人體驗的環境剛才也說了，在這樣的環境下可能：個人體驗環境更注重的是較低門檻比較低，其實在這里我們在這里我們只需要一臺虛擬機的配制配置就可以達到這個目的。我們會然后可以把管理節點、DB節點、數據節點和其他的節點都部署在這臺機器上。當然在體驗的環境下，數據節點和其他的節點，這兩個功能根據機器的配制來看，我們可以不進行部署。

在測試環境：該環境換機下注重的是性能、功能。

首先從管理節點來看，其實管理節點提供的是元原數據的管理和任務的分發功能，他對于性能要求不是很強，他其實要求的是一個穩定性和容災的能力。在測試環境可以稍微弱化這個要求，我們，比如可以準備一臺或者三臺的虛擬機，配置4C/8G普通磁盤就可以了，配制4C/8G；在測試環境下，我們要去要做DB節點的話，其實在DB節點我們要考慮到TDSQL的性能問題，這里我們就會推薦一個使用物理機；我們TDSQL做進行性能測試的時候要求一定是SSD盤，否則我們的性能數據是沒有任何參考性的?！@也是由數據庫的場景決定的，因為SSD和普通的磁盤，一個是隨機，他們方面主要表現在隨機讀寫的能力上，的差距會比較大一點；數據節點和其他的節點方面，如果有一些客戶可能對測試他的功能要求不是那么強沒有那么強，他就可以不部署這些節點的功能，而如果我想體驗一個完整的TDSQL的功能，則我需要準備這些機器，以體驗完整的TDSQL的功能；如果我們要部署數據節點的話，我們可以選擇一臺機器或者三臺機器，虛擬機，以及準備大一較大容量點的磁盤做一個數據節點；其他的節點，這里我們提的是比如負載均衡和日志分析平臺，日志分析平臺的作用剛才也說了，是做一些SQL審計，DB日志分析等等。其實我們TDSQL的負載均衡會比較靈活，他是在我們的位于SQL引擎層上的上一層，這里推薦的有開源自身的LVS，當然也有很多客戶會使用的F5。最后，像這些以上環境我們的推薦是部署兩節點來實現，做一個容災能力。這個其實就是總體而言，為了保證測試的性能，測試環境的要求，要求最多的就是DB這個節點模塊，保證測試的性能。

最終是大家最關心的生產環境的要求，我們這里要求的是：生產環境中要求管理節點，可以部署在三臺或者五臺是虛擬機，但三臺或者五臺，最好是跨三個機房，比如說“1+1+1”的模式或者“2+2+1”的模式，因為我們的原元數據集群是一個基于多數選舉的機制來保障高可用，如果是只有兩個機房的話，則會失去了他本身容災的意義，因此我們建議生產環境這里是中部署三個機房。DB節點生產環境更推薦的是NVME接口的SSD，因為傳統的SSD和NVME的SSD可能體現他的在接口性能上，會有比較大的性能差距。這里而數量上我們推薦的數量是3*N臺，其實——事實上這個是我們要去評估的生產環境TDSQL集群的數據量。因為我們，TDSQL是一個分布式的數據庫，他的數據量級可以根據用戶是根據你的機器數量實現做一個水平拓展擴容。

舉個例子，比如說我們假設客戶有3T的數據，如果（19：39）單臺物理機是1T的話，一個（？）set內做的是一主兩備三個節點，我們此時就需要三個（？）set，三個（？）set可以承擔3T的數據量，同時會有兩個副本復本的冗余，我們DB節點的這些數數就需要9臺這樣的機器，這三個set會組成group shard。數據節點也是的機器也是推薦物理機，這里數據節點在同時在生產環境也需要考慮容災能力，我們因此推薦是三臺機器臺機器以上，這就不推薦1臺機器了，考慮數據節點的容災能力。此外，需要的是一個高性能磁盤，來保證回檔和備份的效率；最后這邊也是推薦物理機，訪問鏈路上接入層是非常重要的一層，我們強烈推薦推進物理機，來提高他的穩定性。

2.2 TDSQlL自動化交付特性與要求

直播回顧 |TDSQL的交付

剛才其實也講到了我們前文講到了TDSQL不同的組件，他分成不同的層次，我們以及我們怎樣去管理這些層次等等其中的層次邏輯。在TDSQL真正交付過程中，為了保證交付質量，結合金融級場景的安全合規、高可用容災考慮，我們沉淀出一些基本要求和特性：

1.網絡：離線部署無外網依賴，機器互通；

2.存儲：支持單磁盤、多磁盤和raid；

3.冷備中心：支持hdfs和掛載式分布式存儲(如ceph)；

4.機器分布：支持跨機架和跨機房上架服務器，支持多種機器分布模式下的高可用容災；

5.CPU：在國產化趨勢下，目前機器CPU除了適配x86，還包括arm、power，而且首要推薦以上其中一款；

6.操作系統：適配支持centos、ubuntu、以及包括國產化操作系統在內的諸多主流操作系統。

其實我們在真正去交付TDSQL的時候，用我們交付方案去交付TDSQL的時候，有一些注意點大家也要注意一下。第一個是我們TDSQL的網絡是沒有外網依賴，因為很多客戶，像一些金融和證券的客戶是不能連通外網，我們在TDSQL的發布包里已經解決了這個依賴。我們只需要一個網絡互通即可，也沒有網端的要求。第二個是存儲，TDSQL既支持讀取物理機上的單磁盤，也支持讀取多磁盤，當然也支持我們多磁盤的raid，然后讀取這個raid的路徑，這些都是可以的。冷備中心這一塊我們TDSQL支持兩種，第一種是hdfs，第二種是遠端掛載式的分布式存儲，比如說ceph的文件系統，他是一種掛載式的文件存儲，比如說以前的NAS、NFS這些也算。

我們建議TDSQL要去跨機架和跨機房上架服務器，我們是有做TDSQL的IDC管理，如果按照我們規范的要求去做，你的實例滿出來的時候，實例內的主備節點本身就是跨機房的關系。當前我們TDSQL支持的CPU有三種，一種是X86系列，這個是之前的主流系列，第二個是arm，arm也是我們現在很多國產化的廠商去做的架構，第三個是power，power目前的主力還是在浪潮這邊。當前客戶主要用的操作系統都做過適配，像centos、ubuntu、紅帽等一些國產化的操作系統，這些我們都有做適配。

右邊這張圖上圖右側展示了我們簡單的簡要分布關系，其實我們就像這樣的規劃一樣，交付過程中我們只要理清楚我們如何把雞蛋放到對應的籃子里就可以了，即可實現自動化交付：我們先選出籃子，一組物理機就是一個例子籃子，我們就隨之把一組的組件DB節點放到這個籃子里，其實這樣就完成了自動化的交付。

2.2.1 靈活交付

直播回顧 |TDSQL的交付

當然這邊其中有很多的細節，客戶最關心的問題是我該怎樣交付這個產品，大家要做的事情就是規劃，其實大家填寫的配置客戶要做的，是自由決定模塊的機械機器分布和集群規模。我們，TDSQL可以通過一個模塊之間填寫的數量不同的數量差異，會自適應地做但點做出單點方案和多節點高可用容災方案。這個過程是用戶在操作上是無感知的。

舉個例子，比如說剛才說的TDSQL是支持HDFS作為做他的冷備中心，如果我們HDFS選的是一個節點的話，他系統會做的一個HDFS的一個但點單點方案。我們知道HDFS的但點方案主要是由（25：38）組成。如果我們這邊填的是三節點的配置規劃，他它會自動感知到我要做的是一個高可用的容災方案。當時HDFS主流的用的高可用容災方案，一個是QJM，一個是基于（？）做的方案。我們當前是用是基于的QJM的方案，他其實包含了（26：07）高可用的方案方式。

2.2.2 簡單高效：整個部署過程最快僅需9分鐘

直播回顧 |TDSQL的交付

剛才說了TDSQL其實除了我們要做一個做完部署規劃，把怎樣的組件放到哪一組機器上，我們要做的，第二件事情是解決各個組件之間的一些關系，包括一些兼容性的等問題。我舉個例子，這次如果部署的TDSQL環境是基于ARM國產服務器的操作系統的國產化的環境，是急于arm平臺的操作系統。我怎樣我們如何通過一個交付的物料包去適配不同的環境？其實秘密就在這個配置文件里：

1.用戶無需關注TDSQL較為復雜的各模塊的互相依賴和配置管理問題，只需要根據實際，填寫變量文件配置即可；

2.用戶填寫一個機器規格配置文件、一個變量配置文件，填寫后可以適配操作系統和CPU實現一鍵自動化交付；

3.操作簡單用戶可獨立完成，自動化部署命令可重復執行，在北京信通院機構現場對TDSQL產品化的測試顯示，整個部署過程最快僅需9分鐘。

2.2.3適配與集成：國產化、全棧式

直播回顧 |TDSQL的交付

客戶就可以通過填寫我們的配置文件。其實已經做了一些適配，包括對我們的內核包，首先對我們的TDSQL的內核包是出了不同CPU架構的內核包。還有對我們交付邏輯上做了對各個操作系統和CPU的兼容。其實客戶無須關心TDSQL比較復雜的模塊之間的依賴和配置關系，只要根據實際情況填寫變量的配置文件就可以了，填寫完了以后就可以執行我們交付的發起命令，可以一鍵自動化交付。

整個交付過程是非常簡單的過程，之前我們有對整個TDSQL的自動化交付過程進行測試，當時是在北京的信通院的一個機構，對TDSQL產品化的交付進行測試，整個過程在搭建TDSQL核心交付場景的情況下，只需要9分鐘就可以完成一個交付的場景。其實到這里我們核心的交付流程已經給大家介紹完了，其實很簡單，我們根據自己的需求把不同的雞蛋放到不同的籃子里，將不同角色的組件放到我們準備好的一組一組機器上，這是第一件事情，填寫規劃的配置文件。第二件事情是填寫依賴的變量文化，包括一些環境和操作系統CPU的變量文件，以幫助我們自適應的調整當前的環境是怎樣的，去調整一些交付的邏輯。第三個我們真正執行交付命令，這個步驟都一鍵化的。

剛才有說到我們TDSQL在國產化方面也做了很多工作，當前國產化已經成為一個趨勢，TDSQL在國產化適也做了很多工作，從我們底層的服務器到存儲器、操作系統、CPU、行業軟件、數據庫軟件等，都是在相關部門指導下國家的領導下進行了聯系與各個廠商合作實現從下層到上層全方位的做國產化適配。在國產化的浪潮下，我們TDSQL作為一個騰訊自研分布式數據庫，他作為一個優秀的國產化數據庫，其實我們也是義不容辭的擔當了我們國產化的責任。我們當前其實是從CPU、操作系統都去做兼容，操作系統剛才有幾個沒有說到。centos、ubuntu、suse，像這幾個可能是大家常見的主流操作系統，包括騰訊內部的操作系統tlinux是騰訊內部的一個操作系統，以及中標麒麟、銀河麒麟、UOS是等常見的主流國產化操作系統，我們都有TDSQL都完成了適配。除了我們列出來的這些CPU的適配、操作系統的適配，適配全系國產操作系統，TDSQL同時已相繼完成對全系國產芯片，全系列國產服務器等的兼容適配工作。而在完成適配工作的同時，騰訊也提供了對應的技術服務，幫助行業用戶更好地遷移到國產基礎技術生態當中。剛才提到有很多服務器CPU的一些硬件廠商做國產化，我們和浪潮也做了一些測試和認證，并且拿到了浪潮的認證，除了浪潮的以外，我們還在很多其他的國產化的客戶項目中，可能更多偏向于政府和國企相關，也同時并行做這些國產化的項目，并且已經拿到了一定的成果。這個些是我們對國產化的方面的工作。

技術服務生態方面，TDSQL其實不僅可作為一個獨立發布的產品，在TDSQL發展的歷程中，也其實他已經被很多其他的很多平臺廠商各種和合作伙伴接納，包括騰訊內部主要是的TCE、Tstack、MDB架構等。TCE是騰訊云基于金融級別的一個平臺，TDSQL也是和TCE進行高度的集成，包括從我們的在部署方案、告警、用戶權限等等各種維度和TCE進行了深度的集成，可為金融政務機構提供全方位的PaaS基礎技術服務，在完成高性能的分布式架構轉型升級的同時保障金融級穩定高可用。Tstack和MDB也是我們內部的一些平臺，除了我們內部的平臺，還有很多客戶自己的一些平臺。除了客戶自己的業務在使用TDSQL以外，有些TDSQL許多客戶合作伙伴是做一些的行業的解決方案，在他們的解決方案中也集成了TDSQL，把我們TDSQL的能力輸入到他們自己的平臺。

2.2.4 安全保障：秒級監測

直播回顧 |TDSQL的交付

TDSQL在發展中對交付場景做了許多優化：

1.條件檢測：首先會自動對規劃的TDSQL集群下的所有機器做前置檢測，包括機器時間同步、時區一致、端口占用、系統默認sh、機器規格等做檢；

2.環境優化：針對關系型數據庫場景，對系統50處左右進行針對性調優，并解決一些基礎的依賴；

3.機器秒級監控：大部分的監控平臺都是基于分鐘級的，對于金融級數據庫這種敏感場景，分鐘級的監控是不夠的。

我們在交付的場景下也做了一些優化，首先我們會對整個TDSQL規劃的集群下的所有機器做前置檢測，包括常見的機器的時間同步、機器的時區、端口占用、系統默認sh、機器規格。我們會對環境進行優化，剛才有提到一些操作系統的內核參數，針對于關系型數據庫場景，比如說TCB的一些優化，像一些內存參數的優化，其實我們做了一些調優，并解決了一些技術的依賴。還做了一個秒級的監控。其實客戶自己的監控平臺，包括我們本身給客戶提供的監控中心，大部分的監控體系是基于一個分鐘級的，但是數據庫這樣的場景比較特殊，其實很多的問題在分鐘級的監控下，問題的現場就會丟掉，不能暴露問題的本身。所以我們針對這樣的場景做了提供了秒級的監控，我們做了幾個維度，有包括針對機器的IO、CPU、網絡、內存等等多個維度。

2.3 多集群下的自動化交付

前文剛才講的是我們在TDSQL在單集群下的交付場景和交付細節，之前在架構課上的時候我們也介紹了TDSQL多集群的交付方案。其實接下來介紹在多集群下的，我們來看一下交付具體是怎樣進行的。

“同城兩地三中心”部署體系

直播回顧 |TDSQL的交付

直播回顧 |TDSQL的交付

“ 同城三中心”架構顧名思義：在一個城市有A、B、C三個機房，TDSQL仍采用“一主兩備”結構，很顯然我們需要將三個數據節點分別部署在三個機房，其中主節點在一個機房，兩個備節點分別部署在另外兩個機房。同城雙中心的架構下我們是有兩套集群，第一套集群是蛇口這個集群，我們是交付一套集群。然后在觀瀾集群是交付另一個集群。我們在兩個集群之間做了一個異步復制，這個是同城雙中心。第二個是“同城三中心”，我們是架構的部署下，是在一個大集群內，在這個數據庫實例下，我們數據庫實例使用使用的是同IDC異步、跨IDC強同步的方式，然后在這邊上海會有一個強同步的實例，實例之間會做一個DCN的復制實現金融級高可用容災。 “兩地三中心”架構顧名思義：在一個城市有A、B兩個機房，另一個城市有C機房，在第一個城市中TDSQL數據庫實例采用同IDC異步、跨IDC強同步的方式，我們需要在第一個城市將四個數據節點部署在二個機房，其中主節點和一個備節點在一個機房，另外兩個備節點在另一個機房。并且在第一個城市和第二個城市的數據庫實例間，采用的是異步復制，保障金融城市級高可用容災。

“兩地四中心”部署體系

直播回顧 |TDSQL的交付

“最后一種就是兩地四中心”的架構，是一個自動化切換的強同步架構，我們也是兩個實例，第一個實例是深圳的實例，我們是分成三個IDC。舉個例子，一個是福田，一個是蛇口，一個是觀瀾，一個實例跨三的IDC，我們做的一個強同步。第二個實例是在上海，在這兩個實例上也是用的DCN做的實例之間的同步，對任何數據中心及故障都能30秒內切換，并且數據零丟失，性能也穩定可靠，對業務和用戶來說是實現更高的可用性和更低的成本。

1

TDSQL質量保障服務：全生產流程自動化巡檢

剛才有講到了我們TDSQL的一些交付的場景，交付的需求和一些做TDSQL國產化和兼容性一些特性的交付考慮。其實在最重要的地方就是最后，最重要的是我們如何保證TDSQL的交付質量，不僅是交付質量和服務的質量，這一塊我是單獨拿到最后一章給大家介紹。

首先我們TDSQL的交付質量，我們是通過一個叫自動化巡檢的方案保證。TDSQL自動化巡檢的方案我們是通過三個維度控制我們的保障交付質量。

直播回顧 |TDSQL的交付

1.監控指標分析

第一個維護維度基于是依賴TDSQL現有的監控中心，從我們現有的監控體系中去做一些進行相關指標性的分析，包括。當前我們這個指標性的分析也分為兩個維度，第一個維度是當前時刻的指標分析，第二個維度是和歷史時刻的指標分析。什么意思？其實這里就會涉及到一個問題，我們當我們要在驗證一個集群，一個TDSQL的集群是否有問題的時候，我們往往除了要分析此時此刻的集群是否存在有一些異常，是否有一些和告警，是、是否存在有一些資源負載過重等等情況。其實往往，還需要分析歷史性的問題，比如說在歷史我過去在歷史七天中各個指標的曲線是如何的。為什么要分析過去歷史七天的指標曲線？舉個簡單的場景案例，我這邊例如一個場景是在每天下午三點到五點的時候，是業務高峰期，在這個業務高峰期的期間，我可能有很多業務的慢查詢，甚至有一些慢查詢帶來的性能的問題。系統我如何監控在歷史某個時刻出現的問題？比如說我那么我們發起自動化巡檢方案的時候，我是比如是上午8點鐘發起，其實上午8點鐘是我的，適逢業務低峰期，此時是發現不了問題的，所以我們需要對歷史上的指標做進行分析。

方案中具體看一下我們有分析的哪些指標，我們從哪些維度進行分析。我們包括檢測前臺連通性如何，我們、確認告警有沒有正確的發送到客戶手中，我們看一下實例的復制方式。我們的TDSQL有幾種實例的復制方式，有強同步，有異步，也有同IDC異步、跨IDC強同步的復制方式。其實我們在復制方式之間又很多的選項，比如說我們強同步有可推化的選項，其實當強同步發生了可推化以后，他其實是一個潛在的風險，我們要把這種潛在的風險弄出來。還有實例免切節點，當發生主備切換的時候，會產生一個免切節點，如果有這個免切節點的話，我們就知道之前歷史上發生過主備切換，會阻止接下來的自動主備切換方式等，影響我們整個集群的高可用性。

慢查詢是很多性能問題，甚至是一些線網問題比較常見的原因，備延遲，HDFS使用率，還有告警策略對比。其實監控主要分為兩個方面：

第一個是監控指標的采集、上報、搜集，這是我們的監控中心在管負責。除了我們拿到這個監控的數據，我們要對這個。

第二是對監控數據進行分析，我們對我們，并對認為異常的分析進行告警，其實在這些。分析和告警下，就會有一個過程中會遵循一定的策略的問題，我們認為——怎樣的監控數據才是異常的，才有必要告出來告警的？當然我前們TDSQL維護了一套私有云的告警模板。我們，也給客戶提供了一些可配置的、定制化的選項，客戶可以根據自己的實際情況進行告警策略的修改；同時提供基于實踐經驗積累的告警策略對比，以防用戶做出不合理的修改，暴露告警策略的潛在風險。

在這個維度，TDSQL多源同步等模塊可以對數據同步情況進行監控，他們當前同步的穩定性、同步的性能如何，等其他就是各個模塊的告警的監控指標。但是為了以防客戶誤操作或者不合理的修改，我們在這邊也會對告警策略進行對比，將一些明顯不合理或者極為不合理的改動暴露出來，提示給客戶，告訴客戶這條告警策略什么時候被改過，我們建議這邊告警策略是有風險的。

還有我們在TDSQL的同步方式上會有監控，DCN的同步和多源同步的監控，他們當前的同步的穩定性、同步的性能如何，其他就是各個模塊的告警的監控指標。第一個維度就是我們說的從監控數據的角度來進行分析，第二個維度相當于是對第一個維度的補充，第二個維度就比較多，我們首先分析的是機器級的，我們不是采的監控數據，是直接真刀訪問服務器后臺，我們會對機器基的LO、CPU、內存、磁盤、穩定性這些進行檢測。穩定性就表現在有一些服務器可能是一些老服務器，比如說已經運行五年了，我們要告知客戶運行五年的機器可能有風險，還有一些機器可能會經常重寫，我們告訴客戶從各種信息里面看這臺服務器本身的穩定性是有問題的。我們從進程級去考慮，我們關鍵要看的是進程本身的情況，一般進程是有守護進程和工作工程組成的，工作進程是否是正常的，守護進程是否是正常的，當前進程開通的端口是否可以正常的訪問。除了進程本身的問題，還要看一下關鍵進程的配置文件的問題，其實很多的配置文件關系到我們整個TDSQL集群的可用性。

2. 集群環境

還有我們在TDSQL的同步方式上會有監控，DCN的同步和多源同步的監控，他們當前的同步的穩定性、同步的性能如何，其他就是各個模塊的告警的監控指標。第一個維度就是我們說的從監控數據的角度來進行分析，第二個維度相當于是對第一個維度的補充。第二個維度就比較多，我們首先分析的是的分析是機器級的，我們不是通過采的監控數據，是直接真刀訪問服務器后臺，我們會對機器級基的LIO、CPU、內存、磁盤、穩定性這些等進行檢測。穩定性就表現在有一些服務器可能是一些老服務器，比如說已經運行五年了，我們要告知客戶運行五年的機器可能有風險，還有一些機器可能會經常重寫，我們告訴客戶從各種信息里面看這臺服務器本身的穩定性是有問題的。我們從進程級去考慮，我們關鍵要看的是進程本身的情況，一般進程是有守護進程和工作工程組成的，工作進程是否是正常的，守護進程是否是正常的，當前進程開通的端口是否可以正常的訪問。除了進程本身的問題，還要看一下關鍵進程的配置文件的問題，其實很多的配置文件關系到我們整個TDSQL集群的可用性。

我們會對一些關鍵的進程進行掃描，防止客戶手動的誤改或者人為的刪除修改一些關鍵配置錯改、誤改。除了機器級和進程級，我們還會進行實例級進行一的些定制化的掃描，其實這個就體現在實例的體檢模塊。之前我們的課程也有分享過扁鵲的工具，實例的體檢就是TDSQL智能診斷分析平臺“扁鵲”工具的接口，可以為實例提供他會給我們從一個實例，從運營、開發、性能等各個指標做一些的系統性的分析。第四個維度是

集群級層面，我們會關注從低到高，最高就是集群性的維度，在集群性的維度下我們要關注的問題，這個集群各個機器之間是否是同步的，時間是否是同步的，TDSQL是要求各個機器要時間同步。還有、實例下源元數據集群是否是有備份的，他、的備份是否是正常的，以及我們這邊會手工觸發此時此刻的源數據集群的備份。我們會在四個維度對第一個監控項從四個方面做一個補充的掃描等。

3. 自動化演練

在我們以各個維度去掃描當前集群沒有問題的情況下，我們還是要從結果出發TDSQL還會從結果出發，我們會對整個集群做一次P0級別（最高級別）的自動化的演練，演練的場景就是我們正常運營和管理的場景。比如說，包括購買實例、創建用戶、用戶授權、創建庫表，在這個庫表上做一些表結構的變更。在這個實例上我們會做一些、水平的擴容，做一些、垂直的擴容，把他擴到不同的機器上，還會做一些、重做備機，模擬一些重做備機的場景，還有、慢查詢入庫，是否慢查詢，我們可以在制度的分析頁面上可以入庫，還有、備份和回檔，我們會模擬把當年的實例做一次手動的備份，并且拿這個備份是否能回檔到之前我們備份的點以及保證整個回檔和備份的過程，他的數據是一致的等。最后我們系統會對購買的實例進行刪除，他其實實現了閉環，對P0級別的場景做了進行閉環的自動化的演練。

總結來說，TDSQL自動化巡檢方案我們從這三個方面，從我們的指標級，從補充到整個集群環境的進行掃描，以及我們的通過自動化演練，這三個維度確保我們整個交付的集群是安全、穩定、可靠、高可用OK的，并且會生成一個我們的質量報告到客戶以及我們TDSQL的產品研發團隊去參考。

除了我們TDSQL的質量保證除了技術上的保障方案，我們還會做一些產品化的TDSQL同時沉淀了大量產品化工作，幫助用戶快速、方便地使用分布式數據庫。

直播回顧 |TDSQL的交付

比如說當我們的客戶從0到1，他是完全的交付。從交付以后從1到多的話，就是運營和使用的過程了。在這些交付和運營的過程中，我們又會帶來很多的問題，比如說怎么交付？剛才我們只是講了一些交付的特點，交付的概念，怎么去操作呢？其實我們也會做一些產品化的文檔的輸出。第一個文檔就是我們大部分的交付、運營在我們TDSQL的產品文檔上，他還包括我們的巡檢，剛才我們說的自動化巡檢的方案，還有故障處理。當遇到一個告警和故障，我們怎么樣去處理，怎么樣解讀這個故障還有一些前臺的操作指導，我們告警的異常解讀，我們的日常變更擴容等等，他是在我們的產品文檔上。如果我們想做一些POC的測試，我們要對一些場景進行適配的話，可能要考慮到業務側的開發問題，我們有輸出TDSQL最佳實踐的開發指南。還有對標準化測試這樣的情況下我們輸出我們POC的用例，提供了性能的用例、功能用例、高可用容災用例。

我們也會對客戶的信息進行定期的維護，首先我們會對客戶定期發起一個集群的巡檢，通過這個巡檢我們可以保證客戶當前以及歷史一段時間內，客戶的環境是沒有問題的。剛才也說了巡檢主要進行功能性和容災性的演練。通過自動的我們的定期的巡檢，會搜集到客戶的環境和版本信息，我們會把這些信息更新到我們的客戶管理系統中，更新的信息是用來之后做客戶私有云的版本推送。在我們的管理系統內部會自動進行掃描客戶當前的版本，如果我們掃描到有建議客戶要升級的版本，我們則會自動推送到客戶代表，然后由客戶代表推送推動客戶升級。

直播回顧 |TDSQL的交付

最后是跟我們客戶最后，在客戶日常運營、日常變更相關的中，可能大部分運營面臨的大部分問題是怎么去擴容、升級、處理告警？怎么擴容？我們TDSQL會對各個節點的擴容有一個提供了自動化的擴容方案，可以一鍵的擴容。同樣升級也是提供了前臺化一鍵操作的功，功能，既可以進行點對點的升級，也可以進行整個集群的批量升級，這個也是我們有一個前臺化的升級工具。TDSQL的高可用性一方面在于自身的彈性架構和容災能力，以及數據強一致性。

直播回顧 |TDSQL的交付

可用性方面TDSQL提供了自動化告警處理方案告警其實TDSQL的可用性一方面在于他自身的架構和容災能力，在于他的強濃度告一致的特性，還有我們的監控系統。在我們的監控系統中難免會產生告警的問題，告警問題處理及時與否，處理的方式其實是影響到我們TDSQL集群的可用性。其實在這個問題上，我們自身也是做了很多探索，我們既要平衡客戶實際的告警處理、告警解讀的工作量，也要幫助客戶保證整個集群的質量。我們這邊提出了一個自動化告警分析，將一部分的告警可以自動化的處理，減少客戶自己線網運行的工作量，可實現自動化告警分析，并對部分告警自動處理，減少現網運營的工作量。

剛才我們是以上我們以交付為核心介紹了我們TDSQL在歷史過程中遇到的幾個交付上的挑戰，和針對這些交付挑戰，我們提出的了我們自動化的交付方案，這些交付方案的特性是什么，我們如何完成我們的交付，我們在這個交付上可以使用的特性，他的兼容性場景有哪些。以及最后我們對整個TDSQL標準化交付的質量和客戶的服務進行了提供了一系列的機制和能力的提升機制和能力方面的提升，關于更多我們TDSQL的細節，可以關注我們TDSQL數據庫公眾號，我們在這個公眾號會有一些定期的推送文章跟大家分享。

PartⅤ Q＆A

Q：TDSQL支持數據庫離線備份嗎？

A：我們TDSQL支持多種備份方式。我們，可以基于物理式的（56：22）的備份，也可以基于邏輯備份。但是我們備份的介質是備份到HDFS或者掛載式的存儲上。整個備份過程其實是在備機上進行備份，備份是，不會影響到我們正常的業務訪問，也不會對業務訪問的性能帶來影響。

Q： TDSQL的告警信息如何接入短信、語音、郵件告警平臺？

A：我們TDSQL的告警接入是比較靈活的，首先我們TDSQL的告警信息是一個文本的形式，他可以發送到任何的平臺，我們當前已經適配過的客戶已經適配過的告警接入方式有很多，比如說客戶有HTTP接口的告警平臺，也有一些其他接口的。其實我們只要根據我們的指引手冊，把我們的告警信息以你根據客戶想要的接口，比如說HTP，我們就發一個HPT的TDSQL可以對應地發一個包，包含了我們的告警信息，發到你的告警接收平臺就可以了。怎么樣告警的接受介質？其實短信、語音、郵件，這個還是由每個客戶自身的告警平臺的能力有影響，比如說自身客戶已經有了一個微信的告警接收的平臺，此時我們TDSQL是接入到客戶微信的告警接收平臺，對于不同的告警接收平臺，TDSQL我們自身針對不同的語音、短信和郵件分別做了不同的告警信息發送。

特惠體驗云數據庫

直播回顧 |TDSQL的交付

↓↓更多驚喜優惠請點這兒~

https://cloud.tencent.com/act/pro/MySQLtry?fromSource=gwzcw.3180840.3180840.3180840&utm_medium=cpc&utm_id=gwzcw.3180840.3180840.3180840

向AI問一下細節

推薦閱讀：

免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。

上一篇新聞：
Oracle游標大全
下一篇新聞：
Oracle SQL Model Clause

猜你喜歡

AI
助
手

產品服務

地區劃分

專題活動

幫助支持

關于我們

售后咨詢

7*24小時在線電話：400-100-2938

7*24小時在線 QQ：800811969

關注億速云

億速云公眾號

手機網站二維碼

亚洲午夜精品一区二区_中文无码日韩欧免_久久香蕉精品视频_欧美主播一区二区三区美女