騰訊云數(shù)據(jù)庫國產(chǎn)數(shù)據(jù)庫專題線上技術沙龍正在火熱進行中，0622畢漢斌的分享已經(jīng)結束，沒來得及參與的小伙伴不用擔心，以下就是直播的視頻和文字回顧。
關注“騰訊云數(shù)據(jù)庫”公眾號，回復“0622畢漢斌”，即可下載直播分享PPT
1
成都創(chuàng)新互聯(lián)專注于大化網(wǎng)站建設服務及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗。 熱誠為您提供大化營銷型網(wǎng)站建設，大化網(wǎng)站制作、大化網(wǎng)頁設計、大化網(wǎng)站官網(wǎng)定制、微信平臺小程序開發(fā)服務，打造大化網(wǎng)絡公司原創(chuàng)品牌,更為您提供大化網(wǎng)站排名全網(wǎng)營銷落地服務。
直播回顧：https://v.qq.com/x/page/v31023ovs5l.html
整
個部署過程最快僅需9
分鐘，
TDSQL全球靈活部署實踐
為幫助開發(fā)者更好地了解和學習分布式數(shù)據(jù)庫技術，2020年3月，騰訊云數(shù)據(jù)庫、云加社區(qū)聯(lián)合騰訊TEG數(shù)據(jù)庫工作組特推出為期3個月的國產(chǎn)數(shù)據(jù)庫專題線上技術沙龍《你想了解的國產(chǎn)數(shù)據(jù)庫秘密，都在這！》邀請數(shù)十位鵝廠資深數(shù)據(jù)庫專家每周二和周四晚上在線深入解讀TDSQL、CDB/CynosDB、TBase三款鵝廠自研數(shù)據(jù)庫的核心架構、技術實現(xiàn)原理和最佳實踐等。本文將帶來直播回顧第七篇，分享TDSQL的部署實踐。
大家好，我是騰訊云TDSQL DBA畢漢斌。我們本次是圍繞著TDSQL交付的話題分享三個方面內容。包括TDSQL曾經(jīng)面臨的交付要求和挑戰(zhàn)，以及我們開發(fā)沉淀的自動化交付方案，最后更重要的是這套質量保障體系后續(xù)可以如何繼續(xù)在交付后的用戶的全生產(chǎn)流程中為用戶提供全方位質量保障。
1
TDSQL交付要求和挑戰(zhàn)：快速給、靈活、安全給
首先我們想講的是TDSQL的交付挑戰(zhàn)，我們也是以三個方面去展開，第一個我們遇到的挑戰(zhàn)是我們TDSQL產(chǎn)品架
構所帶來
的特點：
一是產(chǎn)品化不斷完善帶來的特點——組件多，包括擁有數(shù)據(jù)庫內核，任務分發(fā)、冷備中心、平臺告警、性能診斷等；
1.1 復雜產(chǎn)品組件交付
首先我們從層次上把這些組件進行劃分：赤兔、監(jiān)控采集、OSS、metacluster、扁鵲、onlineddl等可以劃分為一個角色，叫管理節(jié)點。我們從業(yè)務層去講的話，對業(yè)務來說，實際訪問數(shù)據(jù)庫從業(yè)務層去講的話，的過程是，先是負載均衡層，然后負載均衡層會做負載均衡到我們的到SQL引擎層，而SQL引擎層會直接訪問到我們底層的db底層DB，db上也DB上會部署agentAgent，像。圖中左側列這些我們叫做dbDB管理節(jié)點。像右側列如冷備中心、消息隊列、多源同步等，我們一般劃分為數(shù)據(jù)節(jié)點。而日志分析平臺其實就是一個其他的模塊，可劃分為其他的節(jié)點。
像這些節(jié)點之間的也是依賴關系比較復雜，像我們的管理節(jié)點之前有講到，像這些。比如管理節(jié)點，其實主要做的工作就是負責元原數(shù)據(jù)管理，像元原數(shù)據(jù)包括很多，比如以監(jiān)控采集模塊為核心的監(jiān)控數(shù)據(jù)，還有、以任務分發(fā)系統(tǒng)為核心的任務節(jié)點的數(shù)據(jù)。第二個是我們的DB模塊，DB會和管理節(jié)點有一些交付交互，首先——所有的角色不僅是除了DB節(jié)點，還有其他的節(jié)點都會向管理節(jié)點發(fā)送他的監(jiān)控信息，因為都會把監(jiān)控信息發(fā)送上去。而管理節(jié)點也會下發(fā)一些任務，比如說客戶在前臺進行一些的變更，比如說垂直擴容、水平擴容、主備切換，像這些的等變更動作也是會到實際的DB上進行的交付，也會到實際的DB進行交互。數(shù)據(jù)節(jié)點首先會像向管理節(jié)點發(fā)送數(shù)據(jù)，會和DB節(jié)點做一些交付互，比如我們最常用的就是數(shù)據(jù)庫數(shù)據(jù)的備份和回檔，這個就是DB的節(jié)點和數(shù)據(jù)節(jié)點進行交付。日志分析平臺也會和DB節(jié)點去交付，他分析DB節(jié)點產(chǎn)生的日志，具體會做一些用戶的日志分析、SQL分析，甚至會給用戶帶來一些SQL審計的功能，也會向管理節(jié)點上報他的監(jiān)控信息……
所以大家再簡單看一下，其實各個組件之間的依賴關系，可以看得出來他們還是比較復雜的。其實就是因為像我們這樣比較復雜的依賴關系。他，這對于我們的交付是帶來一定的難處。在TDSQL早期我們是通過自身TDSQL產(chǎn)品團隊給客戶做交付。其實按照這樣的要求，這會對交付的人力帶來很大的要求，既即使是我們去的話，部署一個交付的環(huán)境也要兩天以上。
1.2 多場景交付
TDSQL多個場景主要來源于使用TDSQL的對象是不同的，這個對象可以劃分未使用TDSQL的人群是不同的，有個人使用，也有企業(yè)使用，也有第三方平臺使用，包括個人、企業(yè)、第三方平臺。其實這些不同的對象使用TDSQL的過程中，他們的需求和場景也是不同的。以個人使用為例，個人使用TDSQL的話，他更多強調的是我想了解你的產(chǎn)品，學習你的產(chǎn)品，體驗你的產(chǎn)品，個人使用可能更想我能盡量的低門檻快速上手你的產(chǎn)品，盡量的簡單。企業(yè)使用最主要的兩個場景，一個是POC測試，另一個就是我們的和生產(chǎn)場景。POC測試是，關注我們的的是整個產(chǎn)品的性能和功能，包括高可用性、容災能力、國產(chǎn)化適配等。從性能和功能的出發(fā)，也會帶來不同的場景需求。生產(chǎn)其實我們更多關注的是整個交付、整個產(chǎn)品、整個集群，是否有高可用性，是否有容災能力，是否有一次性的保證。我們的平臺接入會帶來更多的挑戰(zhàn)，我們的平臺可能會涉及到一些國產(chǎn)化交付的項目，國產(chǎn)化其實會對我們帶來一些兼容性的問題，還會對我們的標準對接、接入帶來一些需求。
所以由于不同的對象使用我們TDSQL的產(chǎn)品，就會帶來不同場景的需求如何高效滿足？
我
們當時想的是我們TDSQL在交付的場景下，我們是要做多個分支去適配不同的場景，還是用一個分支去適配不同
的場景？
當然我們是用一個分支去適配不同的場景。
1.2 TDSQlL交付質量保障：安全、合規(guī)、多層級實時掃描
第三個挑戰(zhàn)也是，由于時間的推移，我們負責TDSQL去交付的人產(chǎn)生了變化。早期我們TDSQL交付是由我們TDSQL產(chǎn)品研發(fā)團隊，我們、DBA同學去現(xiàn)場給客戶做交付。其實在我們的產(chǎn)品研發(fā)團隊和DBA團隊，大家都是一個團隊，團隊內由于長期的的合作協(xié)同是有是形成了標準和質量可靠，他的交付質量也是有保證的。而隨著我們TDSQL產(chǎn)品化，做大做強，對外推廣用戶規(guī)模不斷擴大以后，其實會產(chǎn)生交付人員的不同交付人員會發(fā)生變化，當然也有一部分是我們產(chǎn)品研發(fā)團隊直接交付。還有一部分是由我們騰訊專門的交付團隊去交付，還有是由我們騰訊內部的第三方平臺以及騰訊外部客戶自己的第三方平臺接入了TDSQL產(chǎn)品，他們第三方平臺負責交付。還有也是客戶自己本身去做交付。不同的交付實施方，他們的操作和使用的過程中就會帶來一些隱患，這些隱患主要體現(xiàn)在以下方面如果不夠標準化，則容易帶來隱患，體現(xiàn)在幾個方面：
第一個是安全的方面。比如說我們環(huán)境的安全，我們知道數(shù)據(jù)庫場景是一個對內存、CPU、硬盤、LOIO的等能力，都是要求比較高的場景。之前遇到的一個case，一個客戶在數(shù)據(jù)庫的場景下，他（9：22）沒有關，在壓力比較高的情況下，由于性能問題，最終在一定的場景下帶來的一些風險的問題，其實這些就是對環(huán)境的優(yōu)化。其實不僅僅是這種環(huán)境優(yōu)化，包括數(shù)據(jù)庫進程會讀大量的文獻，他最大的文獻數(shù)繼承的是系統(tǒng)用戶的最大文件數(shù)。像這些的設置，包括數(shù)據(jù)庫場景對TCP的一些內核參數(shù)的優(yōu)化等這些工作都是作為潛在風險來統(tǒng)一考慮的。像這些優(yōu)化其實是作為式一個潛在的風險去考慮的。
第二個是監(jiān)控方面。對整個集群、進程、機器的監(jiān)控，提到監(jiān)控還有一個以及自動的拉起，有很多即機械機器級別等的故障，故障之后一個，進程快速恢復的能力，其實要考慮到完善的自動拉起的體系這些都要作為完善的體系來考慮。其他還有比如一些定時任務，比如說包括定時去清理一些日志文獻，清理一些歷史上的數(shù)據(jù)，否則磁盤就會撐滿的情況，這在生產(chǎn)的環(huán)境上也是風險很大的。還有我們最后是如何保障整個集群的高可用性、容災性、（10：56）能力。剛才說到的是不同的實施人可能會帶來不同的風險，其實除了實施人以外，還有發(fā)布的版本也需要控制。有的時候我們是作為第一方去交付這個產(chǎn)品，有的時候我們有外部的客戶，他們的平臺會交付，不管誰去交付，這個版本是否是一個歷史版本，這個版本是否會有一些歷史的問題和隱患；如何杜絕這些潛在的舊版本帶來的隱患，檢測到這些版本的漏洞等等方面，也是我們交付質量的一個挑戰(zhàn)都是交付質量體系中需要解決的問題。
其實我們TDSQL交付質量服務和保障就是圍繞著上述的一些各方面問題方面，實現(xiàn)由在不同的實施人、實施方去交付我們TDSQL的產(chǎn)品下，都能保證我們TDSQL的投產(chǎn)的質量。這是我們在做的一個事情。
1
TDSQL自動交付方案：全球靈活部署、實時巡檢，最快9分鐘
剛才也說到TDSQL的交付過程中遇到的一些挑戰(zhàn)，我們針對這些上述的挑戰(zhàn)，TDSQL沉淀出了一套TDSQL自動化交付方案。
2.1 自動化交付方案規(guī)劃
剛才說我們TDSQL是基于一個分支去做的來實現(xiàn)多場景、復雜關系下的自動化交付的，其實也可以說是基于三個分支去做的。我們TDSQL內核包，當前有三個分支，是：基于CPU的多分支進行發(fā)布，當前支持X86、arm、power。其實在我們TDSQL對客戶的發(fā)布包中，一個包自動的集成了不同CPU版本的TDSQLpocketpacket，是——以ansible組件為基礎，加上了條件檢測、操作系統(tǒng)調優(yōu)、環(huán)境依賴的解決、安全規(guī)范、兼容性問題，我們對外做的是TDSQL私有云標準的發(fā)布包。像這個包我們是，可針對于客戶不同的場景，剛才說到的不同場景和不同的環(huán)境做的適配。
TDSQL的組件我們剛才分為四個角色，如果想要快速的交付TDSQL集群，大家只要搞清楚一件事情，打個比方說就是把不同的雞蛋放到不同的籃子里。雞蛋其實就是我們說的是指這些組件，分為這四個；籃子就是我們準備的機器，可以是虛擬機，也可以是物理機。
首先首先說一下我們的個人體驗的環(huán)境，個人體驗的環(huán)境剛才也說了，在這樣的環(huán)境下可能：個人體驗環(huán)境更注重的是較低門檻比較低，其實在這里我們在這里我們只需要一臺虛擬機的配制配置就可以達到這個目的。我們會然后可以把管理節(jié)點、DB節(jié)點、數(shù)據(jù)節(jié)點和其他的節(jié)點都部署在這臺機器上。當然在體驗的環(huán)境下，數(shù)據(jù)節(jié)點和其他的節(jié)點，這兩個功能根據(jù)機器的配制來看，我們可以不進行部署。
在測試環(huán)境：該環(huán)境換機下注重的是性能、功能。
首先從管理節(jié)點來看，其實管理節(jié)點提供的是元原數(shù)據(jù)的管理和任務的分發(fā)功能，他對于性能要求不是很強，他其實要求的是一個穩(wěn)定性和容災的能力。在測試環(huán)境可以稍微弱化這個要求，我們，比如可以準備一臺或者三臺的虛擬機，配置4C/8G普通磁盤就可以了，配制4C/8G；在測試環(huán)境下，我們要去要做DB節(jié)點的話，其實在DB節(jié)點我們要考慮到TDSQL的性能問題，這里我們就會推薦一個使用物理機；我們TDSQL做進行性能測試的時候要求一定是SSD盤，否則我們的性能數(shù)據(jù)是沒有任何參考性的?！@也是由數(shù)據(jù)庫的場景決定的，因為SSD和普通的磁盤，一個是隨機，他們方面主要表現(xiàn)在隨機讀寫的能力上，的差距會比較大一點；數(shù)據(jù)節(jié)點和其他的節(jié)點方面，如果有一些客戶可能對測試他的功能要求不是那么強沒有那么強，他就可以不部署這些節(jié)點的功能，而如果我想體驗一個完整的TDSQL的功能，則我需要準備這些機器，以體驗完整的TDSQL的功能；如果我們要部署數(shù)據(jù)節(jié)點的話，我們可以選擇一臺機器或者三臺機器，虛擬機，以及準備大一較大容量點的磁盤做一個數(shù)據(jù)節(jié)點；其他的節(jié)點，這里我們提的是比如負載均衡和日志分析平臺，日志分析平臺的作用剛才也說了，是做一些SQL審計，DB日志分析等等。其實我們TDSQL的負載均衡會比較靈活，他是在我們的位于SQL引擎層上的上一層，這里推薦的有開源自身的LVS，當然也有很多客戶會使用的F5。最后，像這些以上環(huán)境我們的推薦是部署兩節(jié)點來實現(xiàn)，做一個容災能力。這個其實就是總體而言，為了保證測試的性能，測試環(huán)境的要求，要求最多的就是DB這個節(jié)點模塊，保證測試的性能。
最終是大家最關心的生產(chǎn)環(huán)境的要求，我們這里要求的是：生產(chǎn)環(huán)境中要求管理節(jié)點，可以部署在三臺或者五臺是虛擬機，但三臺或者五臺，最好是跨三個機房，比如說“1+1+1”的模式或者“2+2+1”的模式，因為我們的原元數(shù)據(jù)集群是一個基于多數(shù)選舉的機制來保障高可用，如果是只有兩個機房的話，則會失去了他本身容災的意義，因此我們建議生產(chǎn)環(huán)境這里是中部署三個機房。DB節(jié)點生產(chǎn)環(huán)境更推薦的是NVME接口的SSD，因為傳統(tǒng)的SSD和NVME的SSD可能體現(xiàn)他的在接口性能上，會有比較大的性能差距。這里而數(shù)量上我們推薦的數(shù)量是3*N臺，其實——事實上這個是我們要去評估的生產(chǎn)環(huán)境TDSQL集群的數(shù)據(jù)量。因為我們，TDSQL是一個分布式的數(shù)據(jù)庫，他的數(shù)據(jù)量級可以根據(jù)用戶是根據(jù)你的機器數(shù)量實現(xiàn)做一個水平拓展擴容。
舉個例子，比如說我們假設客戶有3T的數(shù)據(jù)，如果（19：39）單臺物理機是1T的話，一個（？）set內做的是一主兩備三個節(jié)點，我們此時就需要三個（？）set，三個（？）set可以承擔3T的數(shù)據(jù)量，同時會有兩個副本復本的冗余，我們DB節(jié)點的這些數(shù)數(shù)就需要9臺這樣的機器，這三個set會組成group shard。數(shù)據(jù)節(jié)點也是的機器也是推薦物理機，這里數(shù)據(jù)節(jié)點在同時在生產(chǎn)環(huán)境也需要考慮容災能力，我們因此推薦是三臺機器臺機器以上，這就不推薦1臺機器了，考慮數(shù)據(jù)節(jié)點的容災能力。此外，需要的是一個高性能磁盤，來保證回檔和備份的效率；最后這邊也是推薦物理機，訪問鏈路上接入層是非常重要的一層，我們強烈推薦推進物理機，來提高他的穩(wěn)定性。
2.2 TDSQlL自動化交付特性與要求
剛才其實也講到了我們前文講到了TDSQL不同的組件，他分成不同的層次，我們以及我們怎樣去管理這些層次等等其中的層次邏輯。在TDSQL真正交付過程中，為了保證交付質量，結合金融級場景的安全合規(guī)、高可用容災考慮，我們沉淀出一些基本要求和特性：
1.網(wǎng)絡：離線部署無外網(wǎng)依賴，機器互通；
3.冷備中心：支持hdfs和掛載式分布式存儲(如ceph)；
4.機器分布：支持跨機架和跨機房上架服務器，支持多種機器分布模式下的高可用容災；
5.CPU：在國產(chǎn)化趨勢下，目前機器CPU除了適配x86，還包括arm、power，而且首要推薦以上其中一款；
6.操作系統(tǒng)：適配支持centos、ubuntu、以及包括國產(chǎn)化操作系統(tǒng)在內的諸多主流操作系統(tǒng)
。
其實我們在真正去交付TDSQL的時候，用我們交付方案去交付TDSQL的時候，有一些注意點大家也要注意一下。
第一個是我們TDSQL的網(wǎng)絡是沒有外網(wǎng)依賴，因為很多客戶，像一些金融和證券的客戶是不能連通外網(wǎng)，我們在TDSQL的發(fā)布包里已經(jīng)解決了這個依賴。
我們只需要一個網(wǎng)絡互通即可，也沒有網(wǎng)端的要求。
第二個是存儲，TDSQL既支持讀取物理機上的單磁盤，也支持讀取多磁盤，當然也支持我們多磁盤的raid，然后讀取這個raid的路徑，這些都是可以的。
冷備中心這一塊我們TDSQL支持兩種，第一種是hdfs，第二種是遠端掛載式的分布式存儲，比如說ceph的文件系統(tǒng)，他是一種掛載式的文件存儲，比如說以前的NAS、NFS這些也算。
我們建議TDSQL要去跨機架和跨機房上架服務器，我們是有做TDSQL的IDC管理，如果按照我們規(guī)范的要求去做，你的實例滿出來的時候，實例內的主備節(jié)點本身就是跨機房的關系。當前我們TDSQL支持的CPU有三種，一種是X86系列，這個是之前的主流系列，第二個是arm，arm也是我們現(xiàn)在很多國產(chǎn)化的廠商去做的架構，第三個是power，power目前的主力還是在浪潮這邊。當前客戶主要用的操作系統(tǒng)都做過適配，像centos、ubuntu、紅帽等一些國產(chǎn)化的操作系統(tǒng)，這些我們都有做適配。
右邊這張圖上圖右側展示了我們簡單的簡要分布關系，其實我們就像這樣的規(guī)劃一樣，交付過程中我們只要理清楚我們如何把雞蛋放到對應的籃子里就可以了，即可實現(xiàn)自動化交付：我們先選出籃子，一組物理機就是一個例子籃子，我們就隨之把一組的組件DB節(jié)點放到這個籃子里，其實這樣就完成了自動化的交付。
2.2.1 靈活交付
當然這邊其中有很多的細節(jié)，客戶最關心的問題是我該怎樣交付這個產(chǎn)品，大家要做的事情就是規(guī)劃，其實大家填寫的配置客戶要做的，是自由決定模塊的機械機器分布和集群規(guī)模。我們，TDSQL可以通過一個模塊之間填寫的數(shù)量不同的數(shù)量差異，會自適應地做但點做出單點方案和多節(jié)點高可用容災方案。這個過程是用戶在操作上是無感知的。
舉個例子，比如說剛才說的TDSQL是支持HDFS作為做他的冷備中心，如果我們HDFS選的是一個節(jié)點的話，他系統(tǒng)會做的一個HDFS的一個但點單點方案。我們知道HDFS的但點方案主要是由（25：38）組成。如果我們這邊填的是三節(jié)點的配置規(guī)劃，他它會自動感知到我要做的是一個高可用的容災方案。當時HDFS主流的用的高可用容災方案，一個是QJM，一個是基于（？）做的方案。我們當前是用是基于的QJM的方案，他其實包含了（26：07）高可用的方案方式。
2.2.2 簡單高效：整個部署過程最快僅需9分鐘
剛才說了TDSQL其實除了我們要做一個做完部署規(guī)劃，把怎樣的組件放到哪一組機器上，我們要做的，第二件事情是解決各個組件之間的一些關系，包括一些兼容性的等問題。我舉個例子，這次如果部署的TDSQL環(huán)境是基于ARM國產(chǎn)服務器的操作系統(tǒng)的國產(chǎn)化的環(huán)境，是急于arm平臺的操作系統(tǒng)。我怎樣我們如何通過一個交付的物料包去適配不同的環(huán)境？其實秘密就在這個配置文件里：
1.用戶無需關注TDSQL較為復雜的各模塊的互相依賴和配置管理問題，只需要根據(jù)實際，填寫變量文件配置即可；
2.用戶填寫一個機器規(guī)格配置文件、一個變量配置文件，填寫后可以適配操作系統(tǒng)和CPU實現(xiàn)一鍵自動化交付；
3.操作簡單用戶可獨立完成，自動化部署命令可重復執(zhí)行，在北京信通院機構現(xiàn)場對TDSQL產(chǎn)品化的測試顯示，整個部署過程最快僅需9分鐘。
2.2.3適配與集成：國產(chǎn)化、全棧式
客戶就可以通過填寫我們的配置文件。其實已經(jīng)做了一些適配，包括對我們的內核包，首先對我們的TDSQL的內核包是出了不同CPU架構的內核包。還有對我們交付邏輯上做了對各個操作系統(tǒng)和CPU的兼容。其實客戶無須關心TDSQL比較復雜的模塊之間的依賴和配置關系，只要根據(jù)實際情況填寫變量的配置文件就可以了，填寫完了以后就可以執(zhí)行我們交付的發(fā)起命令，可以一鍵自動化交付。
整個交付過程是非常簡單的過程，之前我們有對整個TDSQL的自動化交付過程進行測試，當時是在北京的信通院的一個機構，對TDSQL產(chǎn)品化的交付進行測試，整個過程在搭建TDSQL核心交付場景的情況下，只需要9分鐘就可以完成一個交付的場景。其實到這里我們核心的交付流程已經(jīng)給大家介紹完了，其實很簡單，我們根據(jù)自己的需求把不同的雞蛋放到不同的籃子里，將不同角色的組件放到我們準備好的一組一組機器上，這是第一件事情，填寫規(guī)劃的配置文件。第二件事情是填寫依賴的變量文化，包括一些環(huán)境和操作系統(tǒng)CPU的變量文件，以幫助我們自適應的調整當前的環(huán)境是怎樣的，去調整一些交付的邏輯。第三個我們真正執(zhí)行交付命令，這個步驟都一鍵化的。
剛才有說到我們TDSQL在國產(chǎn)化方面也做了很多工作，當前國產(chǎn)化已經(jīng)成為一個趨勢，TDSQL在國產(chǎn)化適也做了很多工作，從我們底層的服務器到存儲器、操作系統(tǒng)、CPU、行業(yè)軟件、數(shù)據(jù)庫軟件等，都是在相關部門指導下國家的領導下進行了聯(lián)系與各個廠商合作實現(xiàn)從下層到上層全方位的做國產(chǎn)化適配。在國產(chǎn)化的浪潮下，我們TDSQL作為一個騰訊自研分布式數(shù)據(jù)庫，他作為一個優(yōu)秀的國產(chǎn)化數(shù)據(jù)庫，其實我們也是義不容辭的擔當了我們國產(chǎn)化的責任。我們當前其實是從CPU、操作系統(tǒng)都去做兼容，操作系統(tǒng)剛才有幾個沒有說到。centos、ubuntu、suse，像這幾個可能是大家常見的主流操作系統(tǒng)，包括騰訊內部的操作系統(tǒng)tlinux是騰訊內部的一個操作系統(tǒng)，以及中標麒麟、銀河麒麟、UOS是等常見的主流國產(chǎn)化操作系統(tǒng)，我們都有TDSQL都完成了適配。除了我們列出來的這些CPU的適配、操作系統(tǒng)的適配，適配全系國產(chǎn)操作系統(tǒng)，TDSQL同時已相繼完成對全系國產(chǎn)芯片，全系列國產(chǎn)服務器等的兼容適配工作。而在完成適配工作的同時，騰訊也提供了對應的技術服務，幫助行業(yè)用戶更好地遷移到國產(chǎn)基礎技術生態(tài)當中。剛才提到有很多服務器CPU的一些硬件廠商做國產(chǎn)化，我們和浪潮也做了一些測試和認證，并且拿到了浪潮的認證，除了浪潮的以外，我們還在很多其他的國產(chǎn)化的客戶項目中，可能更多偏向于政府和國企相關，也同時并行做這些國產(chǎn)化的項目，并且已經(jīng)拿到了一定的成果。這個些是我們對國產(chǎn)化的方面的工作。
技術服務生態(tài)方面，TDSQL其實不僅可作為一個獨立發(fā)布的產(chǎn)品，在TDSQL發(fā)展的歷程中，也其實他已經(jīng)被很多其他的很多平臺廠商各種和合作伙伴接納，包括騰訊內部主要是的TCE、Tstack、MDB架構等。TCE是騰訊云基于金融級別的一個平臺，TDSQL也是和TCE進行高度的集成，包括從我們的在部署方案、告警、用戶權限等等各種維度和TCE進行了深度的集成，可為金融政務機構提供全方位的PaaS基礎技術服務，在完成高性能的分布式架構轉型升級的同時保障金融級穩(wěn)定高可用。Tstack和MDB也是我們內部的一些平臺，除了我們內部的平臺，還有很多客戶自己的一些平臺。除了客戶自己的業(yè)務在使用TDSQL以外，有些TDSQL許多客戶合作伙伴是做一些的行業(yè)的解決方案，在他們的解決方案中也集成了TDSQL，把我們TDSQL的能力輸入到他們自己的平臺。
2.2.4 安全保障：秒級監(jiān)測
TDSQL在發(fā)展中對交付場景做了許多優(yōu)化：
1.條件檢測：
首先會自動對規(guī)劃的TDSQL集群下的所有機器做前置檢測，包括機器時間同步、時區(qū)一致、端口占用、系統(tǒng)默認sh、機器規(guī)格等做檢；
2.環(huán)境優(yōu)化：針對關系型數(shù)據(jù)庫場景，對系統(tǒng)50處左右進行針對性調優(yōu)，并解決一些基礎的依賴；
3.機器秒級監(jiān)控：大部分的監(jiān)控平臺都是基于分鐘級的，對于金融級數(shù)據(jù)庫這種敏感場景，分鐘級的監(jiān)控是不夠的。
我們在交付的場景下也做了一些優(yōu)化，首先我們會對整個TDSQL規(guī)劃的集群下的所有機器做前置檢測，包括常見的機器的時間同步、機器的時區(qū)、端口占用、系統(tǒng)默認sh、機器規(guī)格。我們會對環(huán)境進行優(yōu)化，剛才有提到一些操作系統(tǒng)的內核參數(shù)，針對于關系型數(shù)據(jù)庫場景，比如說TCB的一些優(yōu)化，像一些內存參數(shù)的優(yōu)化，其實我們做了一些調優(yōu)，并解決了一些技術的依賴。還做了一個秒級的監(jiān)控。其實客戶自己的監(jiān)控平臺，包括我們本身給客戶提供的監(jiān)控中心，大部分的監(jiān)控體系是基于一個分鐘級的，但是數(shù)據(jù)庫這樣的場景比較特殊，其實很多的問題在分鐘級的監(jiān)控下，問題的現(xiàn)場就會丟掉，不能暴露問題的本身。所以我們針對這樣的場景做了提供了秒級的監(jiān)控，我們做了幾個維度，有包括針對機器的IO、CPU、網(wǎng)絡、內存等等多個維度。
2.3 多集群下的自動化交付
前文剛才講的是我們在TDSQL在單集群下的交付場景和交付細節(jié)，之前在架構課上的時候我們也介紹了TDSQL多集群的交付方案。其實接下來介紹在多集群下的，我們來看一下交付具體是怎樣進行的。
“
同城三中心”架構顧名思義：
在一個城市有A、B、C三個機房，TDSQL仍采用“一主兩備”結構，很顯然我們需要將三個數(shù)據(jù)節(jié)點分別部署在三個機房，其中主節(jié)點在一個機房，兩個備節(jié)點分別部署在另外兩個機房。
同城雙中心的架構下我們是有兩套集群，第一套集群是蛇口這個集群，我們是交付一套集群。
然后在觀瀾集群是交付另一個集群。
我們在兩個集群之間做了一個異步復制，這個是同城雙中心。
第二個是“同城三中心”，我們是架構的部署下，是在一個大集群內，在這個數(shù)據(jù)庫實例下，我們數(shù)據(jù)庫實例使用使用的是同IDC異步、跨IDC強同步的方式，然后在這邊上海會有一個強同步的實例，實例之間會做一個DCN的復制實現(xiàn)金融級高可用容災。
“兩地三中心”架構顧名思義：
在一個城市有A、B兩個機房，另一個城市有C機房，在第一個城市中TDSQL數(shù)據(jù)庫實例采用同IDC異步、跨IDC強同步的方式，我們需要在第一個城市將四個數(shù)據(jù)節(jié)點部署在二個機房，其中主節(jié)點和一個備節(jié)點在一個機房，另外兩個備節(jié)點在另一個機房。
并且在第一個城市和第二個城市的數(shù)據(jù)庫實例間，采用的是異步復制，保障金融城市級高可用容災。
“最后一種就是兩地四中心”的架構，是一個自動化切換的強同步架構，我們也是兩個實例，第一個實例是深圳的實例，我們是分成三個IDC。
舉個例子，一個是福田，一個是蛇口，一個是觀瀾，一個實例跨三的IDC，我們做的一個強同步。
第二個實例是在上海，在這兩個實例上也是用的DCN做的實例之間的同步，對任何數(shù)據(jù)中心及故障都能30秒內切換，并且數(shù)據(jù)零丟失，性能也穩(wěn)定可靠，對業(yè)務和用戶來說是實現(xiàn)更高的可用性和更低的成本。
1
TDSQL質量保障服務：全生產(chǎn)流程自動化巡檢
剛才有講到了我們TDSQL的一些交付的場景，交付的需求和一些做TDSQL國產(chǎn)化和兼容性一些特性的交付考慮。其實在最重要的地方就是最后，最重要的是我們如何保證TDSQL的交付質量，不僅是交付質量和服務的質量，這一塊我是單獨拿到最后一章給大家介紹。
首先我們TDSQL的交付質量，我們是通過一個叫自動化巡檢的方案保證。TDSQL自動化巡檢的方案我們是通過三個維度控制我們的保障交付質量。
第一個維護維度基于是依賴TDSQL現(xiàn)有的監(jiān)控中心，從我們現(xiàn)有的監(jiān)控體系中去做一些進行相關指標性的分析，包括。當前我們這個指標性的分析也分為兩個維度，第一個維度是當前時刻的指標分析，第二個維度是和歷史時刻的指標分析。什么意思？其實這里就會涉及到一個問題，我們當我們要在驗證一個集群，一個TDSQL的集群是否有問題的時候，我們往往除了要分析此時此刻的集群是否存在有一些異常，是否有一些和告警，是、是否存在有一些資源負載過重等等情況。其實往往，還需要分析歷史性的問題，比如說在歷史我過去在歷史七天中各個指標的曲線是如何的。為什么要分析過去歷史七天的指標曲線？舉個簡單的場景案例，我這邊例如一個場景是在每天下午三點到五點的時候，是業(yè)務高峰期，在這個業(yè)務高峰期的期間，我可能有很多業(yè)務的慢查詢，甚至有一些慢查詢帶來的性能的問題。系統(tǒng)我如何監(jiān)控在歷史某個時刻出現(xiàn)的問題？比如說我那么我們發(fā)起自動化巡檢方案的時候，我是比如是上午8點鐘發(fā)起，其實上午8點鐘是我的，適逢業(yè)務低峰期，此時是發(fā)現(xiàn)不了問題的，所以我們需要對歷史上的指標做進行分析。
方案中具體看一下我們有分析的哪些指標，我們從哪些維度進行分析。我們包括檢測前臺連通性如何，我們、確認告警有沒有正確的發(fā)送到客戶手中，我們看一下實例的復制方式。我們的TDSQL有幾種實例的復制方式，有強同步，有異步，也有同IDC異步、跨IDC強同步的復制方式。其實我們在復制方式之間又很多的選項，比如說我們強同步有可推化的選項，其實當強同步發(fā)生了可推化以后，他其實是一個潛在的風險，我們要把這種潛在的風險弄出來。還有實例免切節(jié)點，當發(fā)生主備切換的時候，會產(chǎn)生一個免切節(jié)點，如果有這個免切節(jié)點的話，我們就知道之前歷史上發(fā)生過主備切換，會阻止接下來的自動主備切換方式等，影響我們整個集群的高可用性。
慢查詢是很多性能問題，甚至是一些線網(wǎng)問題比較常見的原因，備延遲，HDFS使用率，還有告警策略對比。其實監(jiān)控主要分為兩個方面：
第一個是監(jiān)控指標的采集、上報、搜集，這是我們的監(jiān)控中心在管負責。除了我們拿到這個監(jiān)控的數(shù)據(jù)，我們要對這個。
第二是對監(jiān)控數(shù)據(jù)進行分析，我們對我們，并對認為異常的分析進行告警，其實在這些。分析和告警下，就會有一個過程中會遵循一定的策略的問題，我們認為——怎樣的監(jiān)控數(shù)據(jù)才是異常的，才有必要告出來告警的？當然我前們TDSQL維護了一套私有云的告警模板。我們，也給客戶提供了一些可配置的、定制化的選項，客戶可以根據(jù)自己的實際情況進行告警策略的修改；同時提供基于實踐經(jīng)驗積累的告警策略對比，以防用戶做出不合理的修改，暴露告警策略的潛在風險。
在這個維度，TDSQL多源同步等模塊可以對數(shù)據(jù)同步情況進行監(jiān)控，他們當前同步的穩(wěn)定性、同步的性能如何，等其他就是各個模塊的告警的監(jiān)控指標。但是為了以防客戶誤操作或者不合理的修改，我們在這邊也會對告警策略進行對比，將一些明顯不合理或者極為不合理的改動暴露出來，提示給客戶，告訴客戶這條告警策略什么時候被改過，我們建議這邊告警策略是有風險的。
還有我們在TDSQL的同步方式上會有監(jiān)控，DCN的同步和多源同步的監(jiān)控，他們當前的同步的穩(wěn)定性、同步的性能如何，其他就是各個模塊的告警的監(jiān)控指標。第一個維度就是我們說的從監(jiān)控數(shù)據(jù)的角度來進行分析，第二個維度相當于是對第一個維度的補充，第二個維度就比較多，我們首先分析的是機器級的，我們不是采的監(jiān)控數(shù)據(jù)，是直接真刀訪問服務器后臺，我們會對機器基的LO、CPU、內存、磁盤、穩(wěn)定性這些進行檢測。穩(wěn)定性就表現(xiàn)在有一些服務器可能是一些老服務器，比如說已經(jīng)運行五年了，我們要告知客戶運行五年的機器可能有風險，還有一些機器可能會經(jīng)常重寫，我們告訴客戶從各種信息里面看這臺服務器本身的穩(wěn)定性是有問題的。我們從進程級去考慮，我們關鍵要看的是進程本身的情況，一般進程是有守護進程和工作工程組成的，工作進程是否是正常的，守護進程是否是正常的，當前進程開通的端口是否可以正常的訪問。除了進程本身的問題，還要看一下關鍵進程的配置文件的問題，其實很多的配置文件關系到我們整個TDSQL集群的可用性。
還有我們在TDSQL的同步方式上會有監(jiān)控，DCN的同步和多源同步的監(jiān)控，他們當前的同步的穩(wěn)定性、同步的性能如何，其他就是各個模塊的告警的監(jiān)控指標。第一個維度就是我們說的從監(jiān)控數(shù)據(jù)的角度來進行分析，第二個維度相當于是對第一個維度的補充。第二個維度就比較多，我們首先分析的是的分析是機器級的，我們不是通過采的監(jiān)控數(shù)據(jù)，是直接真刀訪問服務器后臺，我們會對機器級基的LIO、CPU、內存、磁盤、穩(wěn)定性這些等進行檢測。穩(wěn)定性就表現(xiàn)在有一些服務器可能是一些老服務器，比如說已經(jīng)運行五年了，我們要告知客戶運行五年的機器可能有風險，還有一些機器可能會經(jīng)常重寫，我們告訴客戶從各種信息里面看這臺服務器本身的穩(wěn)定性是有問題的。我們從進程級去考慮，我們關鍵要看的是進程本身的情況，一般進程是有守護進程和工作工程組成的，工作進程是否是正常的，守護進程是否是正常的，當前進程開通的端口是否可以正常的訪問。除了進程本身的問題，還要看一下關鍵進程的配置文件的問題，其實很多的配置文件關系到我們整個TDSQL集群的可用性。
我們會對一些關鍵的進程進行掃描，防止客戶手動的誤改或者人為的刪除修改一些關鍵配置錯改、誤改。除了機器級和進程級，我們還會進行實例級進行一的些定制化的掃描，其實這個就體現(xiàn)在實例的體檢模塊。之前我們的課程也有分享過扁鵲的工具，實例的體檢就是TDSQL智能診斷分析平臺“扁鵲”工具的接口，可以為實例提供他會給我們從一個實例，從運營、開發(fā)、性能等各個指標做一些的系統(tǒng)性的分析。第四個維度是
集群級層面，我們會關注從低到高，最高就是集群性的維度，在集群性的維度下我們要關注的問題，這個集群各個機器之間是否是同步的，時間是否是同步的，TDSQL是要求各個機器要時間同步。還有、實例下源元數(shù)據(jù)集群是否是有備份的，他、的備份是否是正常的，以及我們這邊會手工觸發(fā)此時此刻的源數(shù)據(jù)集群的備份。我們會在四個維度對第一個監(jiān)控項從四個方面做一個補充的掃描等。
在我們以各個維度去掃描當前集群沒有問題的情況下，我們還是要從結果出發(fā)TDSQL還會從結果出發(fā)，我們會對整個集群做一次P0級別（最高級別）的自動化的演練，演練的場景就是我們正常運營和管理的場景。比如說，包括購買實例、創(chuàng)建用戶、用戶授權、創(chuàng)建庫表，在這個庫表上做一些表結構的變更。在這個實例上我們會做一些、水平的擴容，做一些、垂直的擴容，把他擴到不同的機器上，還會做一些、重做備機，模擬一些重做備機的場景，還有、慢查詢入庫，是否慢查詢，我們可以在制度的分析頁面上可以入庫，還有、備份和回檔，我們會模擬把當年的實例做一次手動的備份，并且拿這個備份是否能回檔到之前我們備份的點以及保證整個回檔和備份的過程，他的數(shù)據(jù)是一致的等。最后我們系統(tǒng)會對購買的實例進行刪除，他其實實現(xiàn)了閉環(huán)，對P0級別的場景做了進行閉環(huán)的自動化的演練。
總結來說，TDSQL自動化巡檢方案 我們從這三個方面，從我們的指標級，從補充到整個集群環(huán)境的進行掃描，以及我們的通過自動化演練，這三個維度確保我們整個交付的集群是安全、穩(wěn)定、可靠、高可用OK的，并且會生成一個我們的質量報告到客戶以及我們TDSQL的產(chǎn)品研發(fā)團隊去參考。
除了我們TDSQL的質量保證除了技術上的保障方案，我們還會做一些產(chǎn)品化的TDSQL同時沉淀了大量產(chǎn)品化工作，幫助用戶快速、方便地使用分布式數(shù)據(jù)庫。
比如說當我們的客戶從0到1，他是完全的交付。從交付以后從1到多的話，就是運營和使用的過程了。在這些交付和運營的過程中，我們又會帶來很多的問題，比如說怎么交付？剛才我們只是講了一些交付的特點，交付的概念，怎么去操作呢？其實我們也會做一些產(chǎn)品化的文檔的輸出。第一個文檔就是我們大部分的交付、運營在我們TDSQL的產(chǎn)品文檔上，他還包括我們的巡檢，剛才我們說的自動化巡檢的方案，還有故障處理。當遇到一個告警和故障，我們怎么樣去處理，怎么樣解讀這個故障還有一些前臺的操作指導，我們告警的異常解讀，我們的日常變更擴容等等，他是在我們的產(chǎn)品文檔上。如果我們想做一些POC的測試，我們要對一些場景進行適配的話，可能要考慮到業(yè)務側的開發(fā)問題，我們有輸出TDSQL最佳實踐的開發(fā)指南。還有對標準化測試這樣的情況下我們輸出我們POC的用例，提供了性能的用例、功能用例、高可用容災用例。
我們也會對客戶的信息進行定期的維護，首先我們會對客戶定期發(fā)起一個集群的巡檢，通過這個巡檢我們可以保證客戶當前以及歷史一段時間內，客戶的環(huán)境是沒有問題的。剛才也說了巡檢主要進行功能性和容災性的演練。通過自動的我們的定期的巡檢，會搜集到客戶的環(huán)境和版本信息，我們會把這些信息更新到我們的客戶管理系統(tǒng)中，更新的信息是用來之后做客戶私有云的版本推送。在我們的管理系統(tǒng)內部會自動進行掃描客戶當前的版本，如果我們掃描到有建議客戶要升級的版本，我們則會自動推送到客戶代表，然后由客戶代表推送推動客戶升級。
最后是跟我們客戶最后，在客戶日常運營、日常變更相關的中，可能大部分運營面臨的大部分問題是怎么去擴容、升級、處理告警？怎么擴容？我們TDSQL會對各個節(jié)點的擴容有一個提供了自動化的擴容方案，可以一鍵的擴容。同樣升級也是提供了前臺化一鍵操作的功，功能，既可以進行點對點的升級，也可以進行整個集群的批量升級，這個也是我們有一個前臺化的升級工具。TDSQL的高可用性一方面在于自身的彈性架構和容災能力，以及數(shù)據(jù)強一致性。
可用性方面TDSQL提供了自動化告警處理方案告警其實TDSQL的可用性一方面在于他自身的架構和容災能力，在于他的強濃度告一致的特性，還有我們的監(jiān)控系統(tǒng)。在我們的監(jiān)控系統(tǒng)中難免會產(chǎn)生告警的問題，告警問題處理及時與否，處理的方式其實是影響到我們TDSQL集群的可用性。其實在這個問題上，我們自身也是做了很多探索，我們既要平衡客戶實際的告警處理、告警解讀的工作量，也要幫助客戶保證整個集群的質量。我們這邊提出了一個自動化告警分析，將一部分的告警可以自動化的處理，減少客戶自己線網(wǎng)運行的工作量，可實現(xiàn)自動化告警分析，并對部分告警自動處理，減少現(xiàn)網(wǎng)運營的工作量
。
剛才我們是以上我們以交付為核心介紹了我們TDSQL在歷史過程中遇到的幾個交付上的挑戰(zhàn)，和針對這些交付挑戰(zhàn)，我們提出的了我們自動化的交付方案，這些交付方案的特性是什么，我們如何完成我們的交付，我們在這個交付上可以使用的特性，他的兼容性場景有哪些。以及最后我們對整個TDSQL標準化交付的質量和客戶的服務進行了提供了一系列的機制和能力的提升機制和能力方面的提升，關于更多我們TDSQL的細節(jié)，可以關注我們TDSQL數(shù)據(jù)庫公眾號，我們在這個公眾號會有一些定期的推送文章跟大家分享。
Q：TDSQL支持數(shù)據(jù)庫離線備份嗎？
A：我們TDSQL支持多種備份方式。我們，可以基于物理式的（56：22）的備份，也可以基于邏輯備份。但是我們備份的介質是備份到HDFS或者掛載式的存儲上。整個備份過程其實是在備機上進行備份，備份是，不會影響到我們正常的業(yè)務訪問，也不會對業(yè)務訪問的性能帶來影響。
Q：
TDSQL的告警信息如何接入短信、語音、郵件告警平臺？
A：我們TDSQL的告警接入是比較靈活的，首先我們TDSQL的告警信息是一個文本的形式，他可以發(fā)送到任何的平臺，我們當前已經(jīng)適配過的客戶已經(jīng)適配過的告警接入方式有很多，比如說客戶有HTTP接口的告警平臺，也有一些其他接口的。其實我們只要根據(jù)我們的指引手冊，把我們的告警信息以你根據(jù)客戶想要的接口，比如說HTP，我們就發(fā)一個HPT的TDSQL可以對應地發(fā)一個包，包含了我們的告警信息，發(fā)到你的告警接收平臺就可以了。怎么樣告警的接受介質？其實短信、語音、郵件，這個還是由每個客戶自身的告警平臺的能力有影響，比如說自身客戶已經(jīng)有了一個微信的告警接收的平臺，此時我們TDSQL是接入到客戶微信的告警接收平臺，對于不同的告警接收平臺，TDSQL我們自身針對不同的語音、短信和郵件分別做了不同的告警信息發(fā)送。
↓↓更多驚喜優(yōu)惠請點這兒~
https://cloud.tencent.com/act/pro/MySQLtry?fromSource=gwzcw.3180840.3180840.3180840&utm_medium=cpc&utm_id=gwzcw.3180840.3180840.3180840
分享題目：直播回顧|TDSQL的交付
鏈接地址：http://www.rwnh.cn/article48/jddgep.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供企業(yè)網(wǎng)站制作、面包屑導航、搜索引擎優(yōu)化、品牌網(wǎng)站建設、ChatGPT、電子商務
廣告
![]()
聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源：
創(chuàng)新互聯(lián)
