1.MySQL 8.0
MySQL是一個有二十多年歷史的開源數(shù)據(jù)庫，也是時下互聯(lián)網(wǎng)最流行的開源數(shù)據(jù)庫。愛可生大概從2006年開始做面向各類傳統(tǒng)行業(yè)客戶的MySQL應用推廣和技術服務工作，到現(xiàn)在大概十二年的時間了。
MySQL 8.0在4月19號剛剛發(fā)布有非常多的新的特性，在此挑選了比較重要的幾點來跟大家分享。
首先是 MySQL SQL + NOSQL的新架構。近幾年互聯(lián)網(wǎng)的蓬勃發(fā)展，新興的許多NOSQL數(shù)據(jù)，比如文檔型數(shù)據(jù)庫MongoDB?？紤]到此類業(yè)務場景的需求，MySQL 5.7版本中也支持了Json的數(shù)據(jù)類型，便于操作Json格式的用戶函數(shù)。MySQL 8.0在此基礎上做了更多的優(yōu)化并且開放了新的X 協(xié)議，用來支持NoSQL的API接口。在MySQL系統(tǒng)內(nèi)既能使用SQL查詢，也能使用NoSQL API方式，并且Java、Python、.NET等官方連接器都已加入了X協(xié)議的支持，X 協(xié)議默認是開啟的33060端口。這也體現(xiàn)了MySQL在持續(xù)優(yōu)化，廣泛吸納開源社區(qū)的建議。
關于SQL支持，以往MySQL給大家的印象是SQL支持簡單，不支持復雜類查詢比如說窗口函數(shù)，CTE等。MySQL 8.0 在SQL支持上也做了較多改進，在這些方面目前已基本上和其他的開源數(shù)據(jù)庫甚至一線的商業(yè)數(shù)據(jù)庫不相上下，甚至有一些地方支持的更好，比如Json部分，這部分MariaDB和PG都沒有完全支持，這個地址有更詳細的介紹：
2.為什么需要DBaaS
接下來主要介紹DBaaS 平臺的架構演進以及我們的技術選型。為什么需要DBaaS，主要是基于以下三點原因：
降低開源數(shù)據(jù)庫使用門檻手工->自動化->自助化服務標準化這屆DTCC的總體感受有大量和NewSQL數(shù)據(jù)庫相關的主題，各個大廠都在做自己的基于開源數(shù)據(jù)庫的分支。愛可生還是以支持原生MySQL版本為主，這個也是大家使用最多的，也可以解決大部分業(yè)務場景，我們希望幫助更多傳統(tǒng)企業(yè)，沒有太多自研能力的客戶更好的使用它。自動化運維發(fā)展的越來越成熟，隨著數(shù)據(jù)庫實例的快速增長，運維方式在從手工到自動化，再到自助化的過程，將數(shù)據(jù)庫服務化更快更便捷的提供服務能力給業(yè)務方，支持業(yè)務的快速發(fā)展，不讓數(shù)據(jù)庫成為業(yè)務發(fā)展的瓶頸。服務的標準化，業(yè)務方不需要關心數(shù)據(jù)庫的底層架構，只提需求，平臺自動分配資源提供可靠的數(shù)據(jù)庫服務，將數(shù)據(jù)庫服務做成一種標準服務，這些是DBaaS的重要意義。<DBaaS 平臺的架構演進>
大概在2011年，我們開始了第一代設計，那時在幫移動研究院做一個MySQL RDS平臺，就是把MySQL包裝成標準服務提供給移動企業(yè)客戶。這代架構比較簡單，在控制平面的Manager端負責接受用戶服務請求，下發(fā)指令給Agent端；MySQL用來存管理信息，DBA通過Manager操作管理數(shù)據(jù)庫實例。每個數(shù)據(jù)庫服務器部署的Agent管理該主機的MySQL服務。
第一代的設計主要是通過shell腳本去完成數(shù)據(jù)庫的基本自動化工作，Manager和Agent用Java來開發(fā)，Java調(diào)用shell腳本。DBA來開發(fā)腳本，開發(fā)來開發(fā)調(diào)度框架。
第二代設計我們改良了一代基礎上的一些問題，比如高可用，第一代設計通過腳本的方式只能做到一些簡單的Failover切換，但無法做到MySQL快速failover。第二代的設計基本架構不變，將Manager做了拆分，它拆分出來web服務層和調(diào)度層。增加了額外的HaServer組件，來解決MySQL主從Failover切換。
存在的問題：
環(huán)境依賴，測試覆蓋不足
沒有擴展性，功能全部耦合
Failover無法保證數(shù)據(jù)一致性
配置管理存在單點
監(jiān)控、告警依賴第三方監(jiān)控平臺
備份計劃依靠定時任務，缺失恢復演練
3.設計考量
為了解決這些問題，在第三代設計上我們對架構做較大的調(diào)整和重構，包括這些設計上的考量。
開發(fā)語言Golang/Python/Java架構設計按功能進行微服務拆分
故障域小
可按功能獨立升級
可降級運行
逐級守護
自檢告警
反向告警
支持VPC網(wǎng)絡
安全性RPC鏈路加密GRPC with TLS, 每個服務器生成私鑰
日志無明文密碼，落地加密保存
審計日志
Linux capabilities機制權限細分，避免使用root和sudo
三代的架構中，我們把很多功能拆成多個微服務組件，增加了中間件部分。在組件的命名上里都以U打頭，因為MySQL是My，我們就取Your諧音。哈哈。
控制層面：
Ucore是用來做配置管理的，原來是MySQL單點，如果要解決它的高可用意味著需要給它掛備節(jié)點去冗余它，Ucore是一個分布式KV存儲，自帶的高可用特性，leader節(jié)點掛了會自動選舉新的leader節(jié)點。整個集群的配置信息的保存在這里，其余組件注冊后會看到全局配置信息。
UMC是面向DBA的管理入口，集群管理操作是從UMC進入，而URDS是面向開發(fā)者提供自服務的入口，開發(fā)可以通過該入口申請需要的數(shù)據(jù)庫服務，并管理自己的數(shù)據(jù)庫。
Urman 組件是負責數(shù)據(jù)庫備份調(diào)度管理，所有數(shù)據(jù)庫實例的備份任務調(diào)度都是通過Urman服務去控制，其對應的Agent接收Urman發(fā)出的請求和指令，Agent執(zhí)行備份操作。
Umonitor是用來做監(jiān)控數(shù)據(jù)匯總和展示，它從Ustat中拉去監(jiān)控數(shù)據(jù)。
Ustat負責性能數(shù)據(jù)的采集，包括數(shù)據(jù)庫服務的性能指標及系統(tǒng)層面的資源監(jiān)控。
Uguard負責MySQL服務的高可用切換，Uguard-mgr做切換決策，Uguard Agent負責決策的執(zhí)行。
數(shù)據(jù)層面：
在物理機上部署多個MySQL實例，實例間采用Cgroup方式做資源隔離，包括CPU、內(nèi)存以及磁盤IOPS，用磁盤配額方式管理磁盤空間，資源的規(guī)格由管理員來設定。
Proxy層面：
Uproxy，解決需要讀寫分離的業(yè)務場景，它是一個透明的讀寫分離中間件，所謂透明就是業(yè)務不需要改造，不需要劃分讀地址，寫地址，只提供一個入口，業(yè)務直接訪問中間件。它會自動做讀寫分離，事務發(fā)往主節(jié)點，非顯式事務的查詢語句發(fā)往從節(jié)點，我們做了大量優(yōu)化盡可能減少中間件的性能損耗。
Ushard，解決數(shù)據(jù)需要水平擴展的業(yè)務場景，使用數(shù)據(jù)分片方式，根據(jù)業(yè)務場景選擇合適的拆分字段和拆分函數(shù)將數(shù)據(jù)分散到多個數(shù)據(jù)節(jié)點。
Proxy層面也有高可用守護，這樣整個集群都沒有單點的風險。
我們的目標是把這幾種架構全部在一個平臺管理起來，建議一套統(tǒng)一的運維管理體系，當然現(xiàn)在已經(jīng)實現(xiàn)了這個目標。
4.服務可用性設計
關于服務可用性，主要通過以下幾個維度來介紹。
不只是切換Slave 寫了數(shù)據(jù)怎么辦Slave的可用性復制鏈路的可用性決策者的可用性切換
首先，MySQL切換只是其中一個環(huán)節(jié)，影響業(yè)務連續(xù)性的因素我們都要考慮到。比如從機實例的服務狀態(tài)，從機不能被寫數(shù)據(jù)，復制鏈路的狀態(tài)、降低這些因素的影響才能保障較高的可用性。
我梳理了下MySQL的切換流程大概有11個步驟
逐層守護
逐層守護的意思是指，每層服務都會有它的上層服務負責可用性守護，最外層是數(shù)據(jù)庫服務，然后是守護數(shù)據(jù)庫的客戶端層，再是管理端層，最后是核心層Ucore。
SLA
SLA是一種輔助切換決策的量化機制。不同業(yè)務類型的數(shù)據(jù)庫對可用性和數(shù)據(jù)一致性的要求是不一樣的，比如說日志系統(tǒng)，對可用性訴求大于數(shù)據(jù)一致性; 而交易類系統(tǒng)，數(shù)據(jù)一致性是必須的。因此我們定義了兩種協(xié)議，一種是RPO協(xié)議，一種是RTO協(xié)議。RPO協(xié)議保障數(shù)據(jù)的RPO級別，包含P和PE兩類級別，P類是主從日志無差異，存在一定延遲級別就告警，PE類是日志有差異時不做切換由人工干預。
RTO是保障服務連續(xù)性需求，也分為兩類級別T和TE，T類是切換前如果日志有差異最多允許補償多久。TE類是日志差異較大超過所允許的丟失的極限，這時需要人工干預。設置好SLA協(xié)議，故障時會根據(jù)協(xié)議決策切換邏輯。
5.數(shù)據(jù)可用性
數(shù)據(jù)可用性包括了兩部分，數(shù)據(jù)的備份和數(shù)據(jù)恢復演練。
定義一個運維時間窗口，備份調(diào)度器會根據(jù)備份策略編排任務，如果設置了轉(zhuǎn)儲設備，再自動將備份集轉(zhuǎn)儲。
除了備份以外還有演練，如果只是做完備份就不管了。當需要恢復時也不知道是否一定可恢復，這就需要定期進行演練。我們可以在平臺中設置恢復演練任務，自動幫你做恢復演練，把恢復演練做到日常中除了有備份的，也有演練的任務，這個演練的任務會對你的備份集進行一個恢復的演練。備份產(chǎn)生了以后我們就會在一臺演練機上來做恢復，檢測這個備份是否能夠恢復出來。能恢復出來我們就會認為這個備份機是OK的，其實就是把演練做到了日常中。
6.監(jiān)控設計
監(jiān)控我們原來用的zabbix，現(xiàn)在的選型是Prometheus監(jiān)控框架，它是時序型存儲數(shù)據(jù)比較緊湊也便于查詢，用Grafana展現(xiàn)監(jiān)控數(shù)據(jù)，數(shù)據(jù)采集我們做成單進程模式，利用go channel并行采集多個服務數(shù)據(jù)。
7.DTS設計
數(shù)據(jù)傳輸服務主要我們解決數(shù)據(jù)遷移的應用場景，比如 分布式集群里分片遷移。它的設計要點包括以下內(nèi)容：
l 分布式架構
l 窄帶寬下傳輸效率高于原生
l 全量+增量傳輸
l 支持GTID
l 支持并行回放
l 輸出端支持kafka
l 支持 multi-master, star, fan-in 多種拓撲
l 兼容阿里云、微軟云、原生MySQL
它還可以用于上云,下云，云間的數(shù)據(jù)遷移。這個是DTS的架構和設計圖。
Manager是Leader+Follower架構，自動選主，它負責遷移任務下發(fā)。Agent既可以作為數(shù)據(jù)的提取端，也可以作為數(shù)據(jù)的回放端。通過提取端可以從MySQL的Binlog里提取日志信息，傳遞給回放端，回放端并行回放日志。一個DTS集群可以管理多套的數(shù)據(jù)庫服務，界面設計如下：
8.未來規(guī)劃
1）支持更豐富的開源數(shù)據(jù)庫
根據(jù)用戶的需求支持更多類型的數(shù)據(jù)庫服務。
2）容器化
探索適合數(shù)據(jù)庫的容器化管理方式
3）混合云
公有云+私有云
在一個中心統(tǒng)一管理私有云和公有云的數(shù)據(jù)庫服務。
以上就是【第2個太瘋狂了！奔走相告（mysql云數(shù)據(jù)庫 免費）MySQL云數(shù)據(jù)庫支持跨AZ高可用-MySQL云數(shù)據(jù)庫架構設計與實踐的分享-愛可生】的全部內(nèi)容。
評論