摘要：因為傳統(tǒng)的數(shù)據(jù)庫管理方式在當(dāng)前這種架構(gòu)下依靠手工或者借助簡單的工具是無法應(yīng)對多活架構(gòu)大規(guī)模管理帶來的復(fù)雜性，因此平臺化顯得非常重。我們在做的方案時做了充分調(diào)查及論證，最終沒有選擇這種方式。

蔡鵬，2015年加入餓了么，見證了餓了么業(yè)務(wù)&技術(shù)從0到1的發(fā)展過程，并全程參與了數(shù)據(jù)庫及DBA團隊高速發(fā)展全過程。同時也完成個人職能的轉(zhuǎn)型-由運維DBA到DEV-DBA的轉(zhuǎn)變,也從DB的維穩(wěn)轉(zhuǎn)變到專心為DBA團隊及DEV團隊的賦能。

從時間軸上看我們每年會有一個比較大的前進，我們從人肉->工具化->平臺化->自助化只用了兩年半時間完成全部迭代，其中平臺化&自助化+數(shù)據(jù)庫多活改造我們一口氣用了8個月的時間完成全部開發(fā)及改造工作。

在完成平臺化改造的同時，我們數(shù)據(jù)庫架構(gòu)也從傳統(tǒng)的主從架構(gòu)發(fā)展到異地多活架構(gòu)，這對DBA的挑戰(zhàn)是巨大的，但這也是平臺必須能夠解決的。

因為傳統(tǒng)的數(shù)據(jù)庫管理方式在當(dāng)前這種架構(gòu)下依靠 DBA 手工或者借助簡單的工具是無法應(yīng)對多活架構(gòu) + 大規(guī)模管理帶來的復(fù)雜性，因此平臺化顯得非常重。

隨著平臺化的推進，DBA 職能角色發(fā)也在生變化，過去 DBA 在運維和維護上消耗，現(xiàn)在 DBA 更加專注業(yè)務(wù)做價值輸出。

這里個人覺得 DBA 長期在運維層面過多花費時間不斷修補各種層面漏缺，其實是不健康的，雖然每天很忙但是新問題依舊會很多。

整體功能的概覽

DB-Agent：數(shù)據(jù)采集 + 進程管理 + 遠程腳本 & Linux 命令調(diào)用 + 與平臺耦合的接口

MM-OST：無傷 DDL 系統(tǒng)根據(jù) gh-ost 源碼改造實現(xiàn)多活場景下的數(shù)據(jù)庫發(fā)布

Tinker:go 重寫了 linux crontab 的邏輯支持到秒級 + 管理接口與平臺整合實現(xiàn)調(diào)度集群管理日常任務(wù)調(diào)度

Checksum:多機房數(shù)據(jù)一致性檢查

SQLReview:go 實現(xiàn)的類似開源的Inception SQL審核工具并做了功能上的增強

Luna：優(yōu)化后的報警系統(tǒng)(大規(guī)模實例下如何減少報警且不漏關(guān)鍵報警)

VDBA：報警自動處理系統(tǒng),代替DBA完成對線上DB的冒煙&報警的處理

今天沒有去講一些方法論，這不是我擅長的，我覺得還是能給大家介紹一些具體點的內(nèi)容，這樣可能了解的能清楚一些。

實時監(jiān)控&快速排障

這對于DBA是非常常見的事情，一般出問題或者接到報警，通常都要登錄到服務(wù)器，一通命令敲下來可能花的時間最少兩分鐘，然后得出一個有慢SQL或者其他什么原因。

其實這個診斷過程完全可以被自動化掉，日常處理問題的核心原則是“快”（我們高峰期線上故障一分鐘損失幾萬單）。

而平臺必須能提供這樣的能力，出問題時盡量減少 DBA 思考的時間直接給出現(xiàn)象 + 原因縮短決策時間（甚至必要時系統(tǒng)可以自動處理掉有些問題都不必DBA參與）。

基于我們的監(jiān)控大盤 DBA 可以清晰的知道當(dāng)前全服所有實例是否有異常，那些有異常及是什么類型的異?；蛎盁煻紩逦尸F(xiàn)。

監(jiān)控大盤將 DBA 日常管理過程中所有的命令集都整合到一起。

DBA 只需要簡單的點點按鈕系統(tǒng)就會自動執(zhí)行所有命令并做好 sql 執(zhí)行計劃分析、鎖分析、sql執(zhí)行時間分布、歷史趨勢分析，數(shù)據(jù)庫歷史 processlist 快照查看等常見操作。

雖然這些功能看似簡單但是卻非常實用，提高了DBA故障定位的效率。

報警處理自動化

報警處理自動化目前主要包括：

空間問題自動處理

未提交事物處理

長查詢自動kill

CPU/連接數(shù)據(jù)/thread runing過多分析及處理

復(fù)制無損修復(fù)(1032,1062)

過去在處理復(fù)制數(shù)據(jù)不一致異常時同行都是 skip掉，但是這樣缺陷很多同時會留下數(shù)據(jù)不一致的隱患。

目前我們采用的是解析 binlog的方式來做到較精確修復(fù)，避免了傳統(tǒng)的skip方式的缺陷。有人可能會說目前社區(qū)有很多開源的東西能解決你前面提到的報警問題，為啥非要自己寫一個呢？

比如 pt 工具能幫你處理，auto kill 一些數(shù)據(jù)庫有問題的sql，也能幫你跳過復(fù)制的錯誤，或者 github 上也有開源的實現(xiàn)能做到無損修復(fù)復(fù)制問題？

這里的關(guān)于重復(fù)造輪的問題我覺得是對待開源態(tài)度的問題，開源固然能解決一些問題，但是不同的場景對應(yīng)不同的開源工具。 當(dāng)你把這些輪子拼湊到一起時難以形成一個有機整體。

尤其是你在進行平臺化建設(shè)時必須要考慮清楚這個問題，否則純粹的開源堆砌出來的系統(tǒng)是難以維護的不可靠的，對于開源我們可以用其思想造自己合適的輪子。

MHA自動化管理

在 8.0 之前絕大部分公司高可用實現(xiàn)還是基于HHA。MHA實現(xiàn)不可避免的要解決部署的問題。

最初我們是搞一個部署腳本在跳板機上，mysql 安裝時就打通與跳板機的互信工作然后由該腳本在來打通集群節(jié)點間的互信工作，然后在一個slave 上啟動 mha 管理進程。

或者是將該管理進程固定在集群外面的某一個或者多個服務(wù)器上集中部署&監(jiān)控，然而這樣會有什么問題呢？

重度依賴ssh

搭建過程復(fù)雜

manager 管理節(jié)點外溢到一臺或多臺機器后影響可靠性的因素增多

維護復(fù)雜，配置有效性存疑會因此造成穩(wěn)定性風(fēng)險

與平臺整合過于復(fù)雜，平臺如果要管理監(jiān)控manager節(jié)點需要借助ssh或多帶帶實現(xiàn)一個agent。

這種架構(gòu)管理幾十套或者上百套集群時還能勉強應(yīng)付。當(dāng)上千套時管理就很復(fù)雜整體很脆弱出問題后維護工作量大。

我們在做MHA的方案時做了充分調(diào)查及論證，最終沒有選擇這種方式。

最終我們決定多帶帶搞一套管理方式出來，大致邏輯是依托 agent 來做到，

其基本原理如下：

每個 db-agent 上都獨立實現(xiàn)如下接口

獲取集群拓撲結(jié)構(gòu)&—(self *MHA)GetDBTopology()

生成配置文件—(self *MHA)BuildMHAConfig()

節(jié)點互信—(self *MHA)WriteRsaPubilcKey()

啟動—(self *MHA)StartMHA()

MHA進程實時監(jiān)控—(self *MHA)MHAProcessMonitor()

定時配置文件與拓撲結(jié)構(gòu)匹配巡查—(self *MHA)InspectMHAConfigIsOK()

關(guān)閉—(self *MHA)StopMHA()

切換—(self *MHA)SwitchMHA()

2. 平臺按照一定順序依次調(diào)用上述接口來完成整個MHA的從搭建到管理的全部過程，整個過程完全由平臺來完成，極大的減少了 DBA 維護 MHA 的成本。過去DBA要配置或者MHA切換后的維護時間在2-10分鐘左右現(xiàn)在控制在3秒以內(nèi)。

基于 Agent 的管理更加輕量級，也避免了manager 節(jié)點外溢帶來的各種問題也避免了傳統(tǒng)的部署方式上的復(fù)雜性，維護0成本，與平臺整合非常簡單。

平臺在將上述接口調(diào)用封裝成獨立的 API 后可供其他自動化平臺調(diào)用這將為下一步的完全無人管理提供支持。

資源池&一鍵安裝

過去業(yè)務(wù)擴容需要100臺機器，提交給 base 需求兩天后給你一個 Excel 或者一個 wiki 頁面，我們拿到機器之后去寫一些腳本，通過一些工具或者自動化平臺刷資源環(huán)境檢查和安裝腳本，但是每個人可能做法不一樣，做出來東西五花八門，非常不統(tǒng)一。

別人維護的時候覺得沒有問題，當(dāng)換你維護時候覺得很奇怪，為什么這樣做？不夠整齊劃一，標(biāo)準(zhǔn)化推行不是太好。

我們現(xiàn)在 DBA 基本上不需要關(guān)心這些，DBA只需要看我們資源池是否有空閑機器，如果資源不足只要負責(zé)申請資源即可，其他工作基本都可以由agent自動完成。

擴容與遷移

我們 2015年 到 2016年先后經(jīng)歷了遷移到 CDB 然后又遷移到 RDS 最后又做自己的數(shù)據(jù)庫災(zāi)備系統(tǒng)，期間遷移的集群數(shù)超過 3000+ 套，平均每套集群遷移兩到三次，這么多遷移量，通過人很難完成的。

以災(zāi)備為例，做災(zāi)備時候公司給我們 DBA 的團隊遷移時間是兩周之內(nèi)，那時候?qū)⒔?300 多套集群全部遷移到災(zāi)備機房里面去，實際上我們只用兩天時間。

當(dāng)時我們一個人用了不到一個小時的時間寫了一個從集群搭建到調(diào)用數(shù)據(jù)庫遷移接口的腳本快速的拉起全部遷移任務(wù)。

自動遷移會依托我們調(diào)度集群來完成全部的遷移工作。對于日常的自動擴容遷移，DBA只需要一鍵即可完成全部遷移過程。

這里我們思考一下有什么手段可以完全避免DBA來點這一下按鈕呢？這里我個人覺得對于平臺化的過程其實也是所有操作API化的一個過程，對于這點按鈕的動作本身就是調(diào)用一個API，假設(shè)我們現(xiàn)在有一套更加高度自動化的系統(tǒng)（有的大公司稱為智能系統(tǒng)^_^）能自動判斷出容量不足時自動調(diào)用該API不就完全自動擴容了嗎？

DBA 都不需要去人工觸發(fā)，雖然這是小小的一個操作也能被省略(那么 DBA 后面該何去何從呢？)。

我們現(xiàn)在可以說依靠平臺基本上完成了絕大部分標(biāo)準(zhǔn)化、規(guī)范化的工作，任何一個 DBA 只要通過平臺來完成日常必要的工作，做出來的東西都是整齊劃一的，完全避免人的因素導(dǎo)致的差異。

誤操作閃回

2018年至今我們已經(jīng)做了差不多有4次線上誤操作，我們都在很快的時間幫用戶做到快速回滾。

目前社區(qū)有很多關(guān)于回滾的解決方案，但是充分調(diào)研之后我還是決定自己造輪子（這里又回到前面提到的關(guān)于開源及造輪子的問題）。

這里簡單闡述原因：

開源的優(yōu)點是通用性普適性比較強,但是場景化的定制一般比較麻煩

目前的開源工具都是基于命令行來完成必要的操作的，當(dāng)真的線上需要緊急回滾時還要登錄掉服務(wù)器然后在輸入一堆的參數(shù)解析……

這不符合我對平臺化的要求，既然是平臺化，這一系列的操作起碼必須是能在界面里面選一選、點一點就能完成的。

也就是說使用要足夠簡單，尤其這類緊急操作花費的時間要足夠短,沒必要當(dāng)著一堆開發(fā)的面把命令行敲的賊溜來秀肌肉。

我們的場景復(fù)雜舉例說明：我們有一套集群單表分片是 1024 片，總共分了32套集群，有一天開發(fā)突然找來說有部分數(shù)據(jù)被誤操作了你該如何進行處理？

這里表是被sharding的，開發(fā)可能是不知道這批數(shù)據(jù)落在哪個sharding片里面。所以你必須解析全部的 32 個節(jié)點上的 binlog， 這時你通過開源的腳本吭哧吭哧起了32個進程然后你的cpu爆了，網(wǎng)卡爆了……這里分片解析實際上32個進程是不行的。

如果解析腳本不支持對解析的 rowsEvent.Table表名的正則匹配的話恐怕要起1024個進程……

考慮到上述場景有合適自己場景的解析工具是非常必要的。

這里我用go來實現(xiàn)采用了 github.com/siddontang/go-mysql/replication 解析模塊，實現(xiàn)后的解析工具是一個服務(wù)化的組件，可以多節(jié)點部署應(yīng)對上述sharding的解析場景，被服務(wù)化后可以被平臺直接調(diào)用。

當(dāng)真的出現(xiàn)誤操作時，DBA操作時也不用揪心手抖……所以造每個輪子都有他的理由而不僅僅是愛好。

任務(wù)調(diào)度

我們的調(diào)度服務(wù)其實是用 go 重寫了 linux Crontab 的邏輯并且支持到了秒級，同時也為了方便管理加了一些管理模塊實現(xiàn)服務(wù)化，主要還是方便平臺調(diào)用（也是避免 DBA 手工去配置 crontab ）。

平臺對調(diào)度節(jié)點進行整合實現(xiàn)一個邏輯上的調(diào)度集群(后續(xù)會改造成真正意義上的調(diào)度集群，其實改造方式也簡單，只要在調(diào)度節(jié)點里面加上節(jié)點自動注冊然后加一個簡單的任務(wù)分發(fā)器實現(xiàn)負載均衡即可)，同時對日志功能做了增強，通過調(diào)度可以自動的把執(zhí)行過程中輸出的日志記錄下來方便日后追溯原因。

同時也支持捕獲并記錄調(diào)度腳本 exit code 方便對于有些特殊腳本并非只有成功or 失敗兩種狀態(tài)的記錄。

舉個例子比如一個腳本執(zhí)行過程中可能有會有很多種 panic 的可能，但是如果把這些panic的原因都歸結(jié)為腳本執(zhí)行異常并exit(-1)[系統(tǒng)默認的退出碼]，這樣似乎也是可以的。

但是這樣 DBA 在檢查自己的任務(wù)狀態(tài)時發(fā)現(xiàn)異常時不能直接的定位錯誤而是要去翻具體的執(zhí)行錯誤日志，顯得不夠快捷(這也是用戶體驗的點)。

因此 DBA 在只需要在平臺里面定義好錯誤代碼對照表即可在painc時捕獲異常然后exit(exit_code)即可,當(dāng)DBA巡查自己的任務(wù)時能清晰的知道錯誤原因。

SqlReview

最初我們的 Sql 審核由開源的 Inception 來實現(xiàn)，但是由于我們需要加入更多校驗規(guī)則，需要做一些定制修改，但是團隊內(nèi)對又不太了解 c，所以很多情況下開發(fā)提交發(fā)布 sql 工單后都是由我們的 DBA 在來人肉審核一遍的，我們現(xiàn)在平均每天100+的DDL DBA根本審核不過來即使審核到了還是會漏很多規(guī)則，人工是不能保證一定可靠的。

所以搞自己的審核系統(tǒng)是很必要的，但是要獨立寫一個sql-parser模塊難度還是非常大的，在充分調(diào)研了 python&go 的開源實現(xiàn)后最終選擇了tidb的解析模塊,于是項目很快就落地了。在完全覆蓋Inception的規(guī)則后也做了相關(guān)擴展也就是加入我們自定義的規(guī)則

擴展索引的相關(guān)校驗

冗余索引的校驗(如ix_a(a),ix_ab(a,b))

索引中枚舉類型的校驗

組合索引中不能包含主鍵或者索引

建表時必須包含自增id的主鍵

重復(fù)索引的校驗(如啼笑皆非的ix_a(a), ix_aa(a)求開發(fā)的心里陰影面積？)

組合索引列不能超過3個

組合索引列時間等可能涉及范圍查詢的列(類型)必須放在最后一位(如ix_created_time_userid(created_time,userid)這樣的索引意義大嗎？)

索引泛濫攔截(恨不得每個字段都建立一個索引……)

varchar(N>128)攔截或者提示(警惕!開發(fā)可能要寫like了……)

索引命名規(guī)范檢查(開發(fā)取的索引名稱五花八門,甚至有用的劣質(zhì)orm框架生成一個uuid的索引名稱，當(dāng)DBA在進行執(zhí)行explain時看到這個很頭疼根部看不出到底使用了什么索引,往往還要多執(zhí)行一次show……)

風(fēng)險識別攔截或者放行

刪索引會根據(jù)元數(shù)據(jù)來判斷是否表或者索引是否在使用（這依托大量的元數(shù)據(jù)收集&分析，過去DBA看見刪除操作很頭疼要各種驗證最終在操作時還要集群內(nèi)灰度操作）

禁止刪列操作

Modify操作損失進度檢查(如text->varchar,varchar(100)->varchar(10)等都是禁止的)

Modify操作丟失屬性檢查(改問題很隱蔽可能有天開發(fā)說default值丟失了那多半是某次ddl時modify語句沒有帶上原字段屬性導(dǎo)致的,當(dāng)這引發(fā)故障時肯定有人會指責(zé)DBA為啥你沒審核到?MMP)

禁止跨庫操作(防止開發(fā)通過create table Notmydb.table來意外的給別人創(chuàng)建表)

禁止一切Truncate，Drop操作

內(nèi)建規(guī)范檢查

大字段使用規(guī)范約束(比如一個表里面超過一定比例的varchar,包含longtext等大文本類型)

DB，表，索引命名規(guī)范約束檢查

多活必要的字段及屬性檢查

歷史校驗結(jié)果數(shù)據(jù)沉淀

通過數(shù)據(jù)分析準(zhǔn)確的知道哪些產(chǎn)研或者開發(fā)在上述方面犯錯最多(DBA跟開發(fā)的關(guān)系往往也是斗智斗勇的關(guān)系你懂得……)

這里不得不說的是過去我們?yōu)榱朔乐归_發(fā)違反上述規(guī)則除了人肉審核外還對開發(fā)去培訓(xùn)但是這往往都沒有用該犯的錯誤還是會不斷的犯，所以我們現(xiàn)在基本不在去搞什么培訓(xùn)了,完全由系統(tǒng)自動來完成審核。

這里我一直強調(diào)的是任何標(biāo)準(zhǔn)化/規(guī)范化都是必須能夠?qū)戇M代碼里的否則實施起來必然有缺漏。

多活下的發(fā)布系統(tǒng)

數(shù)據(jù)庫多活的架構(gòu)大致是這樣M?DRC?M這里drc是我們的多機房數(shù)同步工具，這里可以把數(shù)據(jù)庫多活理解成雙Master系統(tǒng)只是用drc代替了雙master下的原生復(fù)制。

這種架構(gòu)下對DBA的維護挑戰(zhàn)還是非常大的時間關(guān)系只分享關(guān)于數(shù)據(jù)庫發(fā)布的相關(guān)內(nèi)容這也是最重要的一塊。

說到數(shù)據(jù)庫發(fā)布基本上就是在說DDL對吧，一直以來DDL對開發(fā)來說都是非常頭疼的，DBA往往會選擇pt工具來完成DDL操作，但是受到pt是基于觸發(fā)器實現(xiàn)的影響DDL期間會產(chǎn)生鎖等待現(xiàn)象這會造成業(yè)務(wù)上的影響，過去我們也在這上面吃過很多次虧。

Alter通過什么方式來進行？

原生DDL多機房并行執(zhí)行

DRC不支持

機房間延遲不可可控,機房內(nèi)延遲巨大

PT-OSC多機房并行執(zhí)行

″ Row模式下大表的DDL會產(chǎn)生大量的binlog IDC間的網(wǎng)絡(luò)瓶頸造成全局性影響

″ Pt工具在不同機房間最終的rename階段時間點不同造成機房間數(shù)據(jù)結(jié)構(gòu)不一致導(dǎo)致DRC復(fù)制失敗最終導(dǎo)致不可控的數(shù)據(jù)延遲

″ 基于觸發(fā)器的實現(xiàn)會產(chǎn)生額外的鎖-對業(yè)務(wù)影響明顯

″ 基于Pt源碼改造困難也難以與平臺整合(3P語言只剩下了python……)

Gh-ost多機房并行執(zhí)行(基于go實現(xiàn))

″ 增量數(shù)據(jù)基于binlog解析實現(xiàn)避免觸發(fā)器的影響

″ 基于Go實現(xiàn)為改造提供可能

關(guān)于go-ost這里不打算多講大家可以去githup上看作者對實現(xiàn)原理的說明

這里還是簡要提一下其大致工作流程

創(chuàng)建中間表臨時表

對該臨時表進行DDL

在master或者slave上注冊slave接收binlog并解析對應(yīng)表的events事件

apply events 到臨時表

從原表copy數(shù)據(jù)到臨時表

cut-over（我們的改造點從這里開始）相當(dāng)于pt的rename階段

我們做了一個協(xié)調(diào)器，每個gh-ost 在 ddl 過程中都上報自己的執(zhí)行進度，同時我們在 cut-over 前加了一層攔截。

必須等待多個 gh-ost 都完成數(shù)據(jù) copy 后，多個 gh-ost 節(jié)點才會同時進入 cut-over 階段。

這樣就保證了多機房同步 rename 進而來避免延遲的產(chǎn)生(事實上我們機房間的延遲都控制在秒級)。這里大家可能會有疑問直接在一個機房做不行嗎？可以依靠drc同步?。?/p>

這里首先drc不支持DDL操作這樣就決定了沒法通過drc同步方式來進行，其次機房間帶寬有限D(zhuǎn)DL期間產(chǎn)生大量binlog會造成帶寬打滿的問題。

我們在進行雙機房同步DDL時為了防止DRC應(yīng)用了gh-ost產(chǎn)生的events DRC會主動丟棄gh-ost產(chǎn)生的binlog具體是根據(jù)tablename

命名規(guī)則來區(qū)分。

對 gh-ost 的改造還包含添加多機房負載均衡功能，由于DB 是多機房部署的，你 gh-ost 工具肯定不能部署在一個機房里(解析binlog速度太慢，copy 數(shù)據(jù)過程非常慢主要是消耗在網(wǎng)絡(luò)上的延時了)。

但是多機房部署也還是不夠的，還得是每個機房都部署幾套 gh-ost 系統(tǒng)。

因為當(dāng)開發(fā)同時 DDL的量比較大時，單臺 gh-ost 系統(tǒng)會因為要解析的 binlog 量非常大導(dǎo)致 cpu、網(wǎng)卡流量非常高，影響性能(跟前面提到的閃回功能是同一個道理)。

搞定發(fā)布系統(tǒng)后 DBA 再也不用苦逼的值班搞發(fā)布了，起初我們搞了一個自動化執(zhí)行系統(tǒng)，每天系統(tǒng)會自動完成絕大多數(shù)的工單發(fā)布工作。后來我們完全交給開發(fā)自行來執(zhí)行。

現(xiàn)在從開發(fā)申請發(fā)布到最終發(fā)布完全由開發(fā)自助完成自助率平均在95%左右極少有DBA干預(yù)的情況。

隨著數(shù)據(jù)庫的不斷進步與完善甚至開始往selfdrive上發(fā)展加之這兩年devops，AIops的快速發(fā)展也許留給傳統(tǒng)運維DBA的時間真的不多了(不是我在鼓吹相信大家也能感受的到)，我想除了時刻的危機感 + 積極擁抱變化外沒有其他捷徑了。

聲明：文章收集于網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系小編及時處理，謝謝！