《360 私有云平臺(tái) MySQL 自動(dòng)化實(shí)現(xiàn)剖析》要點(diǎn)：
本文介紹了360 私有云平臺(tái) MySQL 自動(dòng)化實(shí)現(xiàn)剖析，希望對(duì)您有用。如果有疑問，可以聯(lián)系我們。

HULK 私有云平臺(tái) MySQL 服務(wù)剖析 — MySQL 自動(dòng)化在 HULK 中的實(shí)現(xiàn), 這次的分享題目是：HULK 私有云平臺(tái) MySQL 服務(wù)剖析 — MySQL 自動(dòng)化在 HULK 中的實(shí)現(xiàn).本次分享主要從下面幾個(gè)方面來介紹：

1. HULK 私有云平臺(tái)介紹
2. 現(xiàn)有 MySQL 服務(wù)規(guī)模
3. MySQL 服務(wù)常用功能展示
4. 各功能模塊設(shè)計(jì)實(shí)現(xiàn)思路
5. 新的計(jì)劃

現(xiàn)狀 & 服務(wù)規(guī)模

說起 HULK 私有云平臺(tái)大家有參加過之前我們同事分享的應(yīng)該聽過,360HULK 私有云平臺(tái)是奇虎 360 公司內(nèi)部專屬私有云平臺(tái),平臺(tái)涉及云計(jì)算、數(shù)據(jù)庫、大數(shù)據(jù)、監(jiān)控等眾多技術(shù)領(lǐng)域.今天要分享的 MySQL 服務(wù)就是 HULK 數(shù)據(jù)庫服務(wù)中的一種.

這個(gè)是 HULK 用戶端的首頁,而其中數(shù)據(jù)庫服務(wù)又集合了 MySQL、Redis、Mongodb、Greenplum、ElasticSearch 等,今天的主角是 MySQL,MySQL 作為基礎(chǔ)服務(wù)是 DBA 服務(wù)體系中的基石,在 HULK 云平臺(tái)中,MySQL 實(shí)例數(shù)已經(jīng)突破 9000+,日訪問量超過 200 億,單份數(shù)據(jù)量也已經(jīng)超過了 270TB.

不知道大家跟業(yè)務(wù)或者 DBA 溝通需求通過什么途徑,當(dāng)年我們沒有搞自動(dòng)化之前,需求溝通占用很大一部分工作時(shí)間,并且資源管理、服務(wù)部署等都是體力活,往往業(yè)務(wù)從需求溝通到實(shí)例部署完成,都是小時(shí)計(jì)的,而現(xiàn)在,我們可以做到分鐘級(jí),下面是在使用 HULK 平臺(tái)自動(dòng)化前后的對(duì)比.

實(shí)現(xiàn)全部自動(dòng)化后,業(yè)務(wù)可以隨時(shí)隨地自助的提交數(shù)據(jù)庫申請(qǐng),不受時(shí)間和外部其他因素困擾,并能快速的投入使用,極大的提高了開發(fā)效率.

各功能模塊設(shè)計(jì)實(shí)現(xiàn)思路

下面會(huì)根據(jù)業(yè)務(wù)在 HULK 上從申請(qǐng)到最終下線,貫串整個(gè)流程來演示和分析下各個(gè)模塊的功能和設(shè)計(jì)思路.

創(chuàng)建實(shí)例 ?

先看下創(chuàng)建實(shí)例,目前我們實(shí)例創(chuàng)建做到了全自動(dòng),業(yè)務(wù)之需根據(jù)自己業(yè)務(wù)情況選擇對(duì)應(yīng)的套餐、部署 IDC 以及訪問數(shù)據(jù)庫的機(jī)器列表,即可提交任務(wù),任務(wù)提交后自動(dòng)化完成,時(shí)間視部署 IDC 情況在 30 秒到 1 分鐘之間.這個(gè)是實(shí)例申請(qǐng)頁面,業(yè)務(wù)提交完申請(qǐng),只需要查看工單狀態(tài),完成后具體的數(shù)據(jù)庫連接信息會(huì)郵件發(fā)送.我們底層的任務(wù)系統(tǒng)用的自研的 QCMD,后面有機(jī)會(huì)的話也會(huì)在這里和大家分享,本次不做過多介紹.

而要做到這樣的全自動(dòng),就需要從資源分析控制上入手,怎么合理的分配資源,且能高效的利用,是重點(diǎn)要考慮的問題,下面是我們?cè)谧鲎詣?dòng)化中遇到和解決的幾個(gè)技術(shù)點(diǎn)：

借鑒各個(gè)公有云的模式,我們分析了業(yè)務(wù)的各種需求類型,同時(shí)對(duì)比我們內(nèi)部的數(shù)據(jù)庫資源,將數(shù)據(jù)庫實(shí)例歸類劃分為套餐,不同的套餐對(duì)應(yīng)不同的數(shù)據(jù)庫資源,每臺(tái)服務(wù)器也有自己對(duì)應(yīng)的資源總數(shù),實(shí)例新建、擴(kuò)容、下線等都會(huì)相應(yīng)增刪不同比例的資源.這樣每臺(tái)服務(wù)器理論分配的數(shù)據(jù)庫實(shí)例和對(duì)應(yīng)消耗的資源是可控的.

同時(shí),我們對(duì)服務(wù)器實(shí)際消耗的資源進(jìn)行動(dòng)態(tài)統(tǒng)計(jì)分析,并對(duì)健康狀態(tài)進(jìn)行打分,這樣進(jìn)一步來控制服務(wù)器的資源使用.

自動(dòng)關(guān)聯(lián)監(jiān)控系統(tǒng)比不可少,第一時(shí)間將數(shù)據(jù)庫實(shí)例納入監(jiān)控體系,并且在管理員維護(hù)操作的時(shí)候可以靈活啟停監(jiān)控.

對(duì)機(jī)器資源統(tǒng)計(jì)方面我們重點(diǎn)監(jiān)測(cè)下面 7 個(gè)點(diǎn),有一個(gè)監(jiān)測(cè)點(diǎn)的值超過了對(duì)應(yīng)閾值則處于不同的狀態(tài),在創(chuàng)建實(shí)例自動(dòng)選擇機(jī)器的時(shí)候,將會(huì)按照不同的邏輯選擇.

數(shù)據(jù)庫架構(gòu) & 高可用

實(shí)例創(chuàng)建完成,下圖是我們默認(rèn)的數(shù)據(jù)庫架構(gòu)圖,以雙 IDC 為例,用 Atlas 作為中間層,提供讀寫分離,Atlas 已經(jīng)開源具體可以參考：https://github.com/Qihoo360/Atlas . 在 Atlas 之上用 LVS 做了一次隔離和負(fù)載均衡,其中為了高可用,每個(gè)機(jī)房的服務(wù)節(jié)點(diǎn)都是部署多個(gè),避免單點(diǎn)故障.

當(dāng)單個(gè) Atlas 故障的時(shí)候,LVS 檢測(cè)到異常會(huì)直接下線,而當(dāng)單個(gè)從庫故障的時(shí)候,Atlas 檢測(cè)到也會(huì)下線. 這樣在 Atlas 和從庫單點(diǎn)故障的時(shí)候整個(gè)集群還能正常工作,并且不影響業(yè)務(wù)使用.但是,當(dāng)主庫掛掉的時(shí)候,就改我們的故障自動(dòng)切換 Failover 出場(chǎng)了.

下圖是我們主庫宕機(jī)時(shí)的切換流程,我們的故障切換服務(wù) MySQL Failover 實(shí)時(shí)監(jiān)控集群狀態(tài),當(dāng)發(fā)現(xiàn)主庫宕機(jī)后,會(huì)根據(jù)選主邏輯選出新主庫、補(bǔ)全數(shù)據(jù)、重做主從結(jié)構(gòu)然后修改 Atlas 的配置,到此整個(gè)切換流程完成,MySQL Failover 重新進(jìn)入監(jiān)控狀態(tài).正常情況整個(gè)故障切換耗時(shí) 15s 左右.

建表改表 ?

說完數(shù)據(jù)庫結(jié)構(gòu)和故障切換,按照正常操作流程業(yè)務(wù)們?cè)摻ū?、改表、授?quán)、查看監(jiān)控等操作了,其中授權(quán)監(jiān)控這里就不多贅述了.因?yàn)槲覀兤脚_(tái)默認(rèn)給業(yè)務(wù)方只有對(duì)數(shù)據(jù)的增刪改查權(quán)限,所以建表改表需要業(yè)務(wù)來 HULK 平臺(tái)操作,針對(duì)建表,我們根據(jù)運(yùn)維經(jīng)驗(yàn)和踩坑實(shí)踐,總結(jié)了 16 個(gè)檢查項(xiàng),這里貼出來和大家分享下.

建表語句需要符合一定標(biāo)準(zhǔn),否則將建表失敗,具體審核標(biāo)準(zhǔn)如下：

1. 表結(jié)構(gòu)是否合法；
2. 表名、列明長度超過 16；
3. 必須有 unsigned；
4. 必須為 innodb；
5. int bigint (10) 不能小于 10；
6. varchar 長度小于 3000；
7. text 字段個(gè)數(shù)不能大于 3；
8. 主鍵必須為 int 類型；
9. 索引不能有重復(fù)；
10. 索引個(gè)數(shù)不能大于 5 個(gè)(包括主鍵)；
11. 索引字段必須為 not null,并且有 default 值(除自增鍵外)；
12. SQL 是否使用到索引；
13. 審核的 SQL 不要包含非審核的表；
14. SQL 中不能有 *；
15. 自增字段必須為 int 或者 bigint；
16. 請(qǐng)不要使用 MySQL 預(yù)留字(Reserved Words)；

下面這個(gè)是測(cè)試建表的示例.

改表我們用的是 pt-osc(pt-online-schema-change),不過我們最近也在研究 gh-ost https://github.com/github/gh-ost ,對(duì) gh-ost 感興趣的咱們也可以下來交流.

測(cè)試環(huán)境 ?

為了方便業(yè)務(wù)測(cè)試,我們?cè)谄脚_(tái)上提供了測(cè)試環(huán)境,并且將測(cè)試環(huán)境和線上環(huán)境打通,業(yè)務(wù)可以直接將庫表結(jié)構(gòu)在線上和測(cè)試之間互導(dǎo).方便業(yè)務(wù)測(cè)試和上線操作.

優(yōu)化建議 ?

優(yōu)化建議我們平臺(tái)上目前統(tǒng)計(jì)了三類：慢日志、未使用索引、char 字段,其中慢日志收集了執(zhí)行超過 0.5s 的 sql 以天為單位匯總后使用 pt-query-digest 分析,并將結(jié)果展示在 HULK 平臺(tái).

未使用索引我們使用了 MySQL5.6 中 PS 庫的 table_io_waits_summary_by_index_usage 表的信息,匯總分析出沒有被使用到的索引,重復(fù)索引會(huì)浪費(fèi)存儲(chǔ)空間,同時(shí)對(duì)數(shù)據(jù)更新性能也有影響,在一些場(chǎng)景下,還會(huì)對(duì)查詢優(yōu)化器造成干擾,可謂百害而無一利.

我們另一個(gè)優(yōu)化建議就是 char 字段優(yōu)化了,好多業(yè)務(wù)在建表的時(shí)候喜歡用 char 類型,但是 char 是固定長度,申請(qǐng)多少就占多少空間,當(dāng)存入的字符串長度不夠的時(shí)候會(huì)用空格補(bǔ)齊,這樣在非定長的字符串存儲(chǔ)中 char 會(huì)浪費(fèi)大量的存儲(chǔ)空間,所以我們對(duì)線上的所有字段定期進(jìn)行分析匯總,掃描出使用長度遠(yuǎn)小于申請(qǐng)長度的表和字段,以報(bào)表的方式展示給業(yè)務(wù),方便業(yè)務(wù)及時(shí)優(yōu)化,我們建議直接將 char 改為 varchar,除非存儲(chǔ)的是定長的比如 md5 之類的字符串,否則全部建議用 varchar.varchar 是可變長度的,實(shí)際使用多少就分配多少,額外再用 1-2 字節(jié)存儲(chǔ)長度,并且超過指定長度還可以繼續(xù)寫入.

數(shù)據(jù)恢復(fù) ?

大家關(guān)心的數(shù)據(jù)恢復(fù)來了,不知道大家有沒有這個(gè)經(jīng)歷：不小心誤操作了需要恢復(fù)數(shù)據(jù),但是聯(lián)系 DBA、溝通需求、DBA 數(shù)據(jù)恢復(fù)、業(yè)務(wù)數(shù)據(jù)確認(rèn)、替換上線,這整個(gè)流程走下來可能影響已經(jīng)擴(kuò)大,況且有可能數(shù)據(jù)恢復(fù)的需求在半夜,這個(gè)流程可能又延長很多.出于這種場(chǎng)景的考慮,我們將數(shù)據(jù)恢復(fù)也做成了自動(dòng)化的任務(wù),業(yè)務(wù)可以自助隨時(shí)提交恢復(fù)任務(wù),避免溝通確認(rèn)各個(gè)環(huán)節(jié)浪費(fèi)寶貴的數(shù)據(jù)恢復(fù)時(shí)間.數(shù)據(jù)可以恢復(fù)到 7 天以內(nèi)任意時(shí)間點(diǎn).看操作流程截圖：

業(yè)務(wù)之需選擇需要恢復(fù)的庫表,選擇時(shí)間提交任務(wù)即可,視數(shù)據(jù)量大小耗費(fèi)時(shí)間不一,普通的幾 G 的數(shù)據(jù)表,一般分鐘級(jí)就能恢復(fù),恢復(fù)后會(huì)生成臨時(shí)實(shí)例,業(yè)務(wù)去臨時(shí)實(shí)例確認(rèn)數(shù)據(jù)無誤后就可以一鍵替換線上,完成數(shù)據(jù)恢復(fù)申請(qǐng).

數(shù)據(jù)備份

前面大家也了解了自動(dòng)數(shù)據(jù)恢復(fù),數(shù)據(jù)恢復(fù)依賴于完善的數(shù)據(jù)備份.我們的備份系統(tǒng)各模塊構(gòu)成如下圖：

備份系統(tǒng)特點(diǎn)

多維度備份

全量備份 + 增量備份(binlog),每天都會(huì)進(jìn)行全量備份,同時(shí)實(shí)時(shí)進(jìn)行 binlog 備份.

合理的保留策略

4, 2,2,1 策略,即保留最近 4 天每天的全量備份,最近 2 周,最近 2 月,最近 1 年的全量備份binlog 保留最近 60 天.

?自動(dòng)更新備份策略

策略根據(jù)當(dāng)天狀態(tài)動(dòng)態(tài)刷新,根據(jù)從庫狀態(tài)(我們?cè)趶膸靷浞?,存儲(chǔ)狀態(tài),網(wǎng)絡(luò)狀態(tài)等動(dòng)態(tài)跟新備份策略.

?失敗檢測(cè)預(yù)警

備份失敗自動(dòng)歸類,集中處理.備份失敗檢測(cè)模塊會(huì)將失敗任務(wù)匯總,報(bào)表展示.

?過期自動(dòng)清理

存儲(chǔ)管理模塊會(huì)根據(jù)保留策略,清理過期的備份數(shù)據(jù).

我們備份系統(tǒng)是基于 Percona XtraBackup 實(shí)現(xiàn)的,不過根據(jù)我們的使用場(chǎng)景,做了一些改進(jìn)與提升：

?分庫分表獨(dú)立備份壓縮

我們備份過程中按表為單位單獨(dú)備份打包壓縮,以便于支持單 / 多表快速恢復(fù)

改造支持單 / 多表恢復(fù)

為了快速恢復(fù)我們修改部分備份功能,可以支持?jǐn)?shù)據(jù)恢復(fù)的時(shí)候值拷貝需要恢復(fù)的數(shù)據(jù)表和 MySQL 元數(shù)據(jù)信息, 極大節(jié)省數(shù)據(jù)拷貝、解壓以及數(shù)據(jù)恢復(fù)時(shí)主從數(shù)據(jù)同步時(shí)間.想象下這種場(chǎng)景：源數(shù)據(jù)庫有 1T 數(shù)據(jù),現(xiàn)在需要快速恢復(fù)一張 1G 的數(shù)據(jù)表,如果不支持單表恢復(fù),則需要拷貝 1T 的數(shù)據(jù)并解壓,這恢復(fù)時(shí)間起碼好幾個(gè)小時(shí),但是支持單表恢復(fù)后,拷貝和解壓的數(shù)據(jù)量只有幾 G,分鐘級(jí)就可以恢復(fù).

支持?jǐn)?shù)據(jù)加密和加密傳輸

增加了數(shù)據(jù)加密模塊和加密傳輸模塊

?增加多種恢復(fù)模式

支持時(shí)間點(diǎn),binlog_pos,sql 等多種恢復(fù)模式

從 DBA 和運(yùn)維角度出發(fā),還可以做一些事情來避免機(jī)器級(jí)別的故障：

1. 關(guān)注遠(yuǎn)控報(bào)錯(cuò),有問題及時(shí)遷移實(shí)例報(bào)修
2. 監(jiān)控系統(tǒng)日志,提前發(fā)現(xiàn)故障機(jī)器.有一些硬件故障不會(huì)導(dǎo)致立即宕機(jī),單是個(gè)定時(shí)炸彈,這些信息會(huì)被記錄到系統(tǒng)日志,如 message,mcelog 中,對(duì)這些日志增加監(jiān)控,可以提前發(fā)現(xiàn)有故障隱患的機(jī)器,提前遷移數(shù)據(jù)庫實(shí)例,避免宕機(jī)影響服務(wù).
3. 控制機(jī)器過比率,發(fā)現(xiàn)現(xiàn)在廠商對(duì)過保故障控制的特別到位,一過保,機(jī)器故障率里面飆升,所以我們也對(duì)機(jī)器的過保情況進(jìn)行了統(tǒng)計(jì),避免重點(diǎn)業(yè)務(wù)部署在已過保的機(jī)器上.

新的計(jì)劃

日常操作自動(dòng)化之后,業(yè)務(wù)開發(fā)效率提高同時(shí) DBA 也可以省去之前大量的重復(fù)勞動(dòng),可以有更多的精力來提高服務(wù)質(zhì)量以及研究寫新的技術(shù).以上就是我們 HULK 平臺(tái) MySQL 服務(wù)的一些設(shè)計(jì)思路和實(shí)踐經(jīng)驗(yàn).

QA 環(huán)節(jié)

Q1：未來計(jì)劃的數(shù)據(jù)庫的遷庫操作是怎樣的?是不是開發(fā)人員可以很簡(jiǎn)單地進(jìn)行操作?

A1：數(shù)據(jù)遷移是想實(shí)現(xiàn)從自建的或者非標(biāo)準(zhǔn)的數(shù)據(jù)源將數(shù)據(jù)遷移到我們標(biāo)準(zhǔn)的平臺(tái)上來,并且盡量不影響源數(shù)據(jù)庫的使用.計(jì)劃是做成一個(gè)通用服務(wù),業(yè)務(wù)人員之需填寫數(shù)據(jù)源和目的的相關(guān)配置即可.

Q2: 能詳細(xì)說明一下 dts 實(shí)現(xiàn)當(dāng)時(shí)么,尤其對(duì)于大數(shù)據(jù)庫?

A2: DTS 還在開發(fā)中,后面有機(jī)會(huì)和大家交流.

Q3: 請(qǐng)問你們有做 SQL 操作日志審計(jì)嗎,是如何撲獲 MySQL 執(zhí)行的所有 sql 語句的?

A3: 我們?nèi)康?SQL 日志是通過 Atlas 收集匯總的,上面也有放 Atlas 的 github 連接,感興趣的同學(xué)可以去看看.

Q4：辛苦了!測(cè)試環(huán)境和線上環(huán)境的打通是怎樣做到的,Docker 嗎?

A4: 我們這邊在 HULK 平臺(tái)上通過業(yè)務(wù)的方式來關(guān)聯(lián)服務(wù),同一個(gè)業(yè)務(wù)可以在自己的線上環(huán)境和測(cè)試環(huán)境之間做遷移,DBA 這邊直接通過管理賬號(hào)后臺(tái)打通權(quán)限.

Q5: 請(qǐng)問數(shù)據(jù)庫實(shí)例是安裝在哪里呢, 一臺(tái)物理機(jī)如何部署多個(gè) mysql 實(shí)例?

A5: 數(shù)據(jù)庫實(shí)例是部署在物理機(jī)上的,一臺(tái)物理機(jī)部署多個(gè) MySQL 實(shí)例,可以配置多個(gè)配置文件,設(shè)置不同的數(shù)據(jù)目錄即可.

Q6：每天 100 多萬的訂單在 mysql 庫上如何做,如分片,分庫如果分片,分多少合適?

A6: 這個(gè)得根據(jù)實(shí)際情況來分析,現(xiàn)在硬件性能提升很快,不分片也能抗很大的請(qǐng)求,具體分片需要根據(jù)實(shí)際的數(shù)據(jù)量、訪問量、瞬間并發(fā)量、機(jī)器性能等等來設(shè)計(jì).

Q7：“其中數(shù)據(jù)庫服務(wù)又集合了 MySQL、Redis、Mongodb、Greenplum、ElasticSearch 等”,請(qǐng)問能否介紹下各類數(shù)據(jù)庫的應(yīng)用情況?

A7: Redis 前面有過分享,大家可以找找歷史文章或者找美女環(huán)環(huán)；MongoDB 后面我們準(zhǔn)備也有一起分享,先留點(diǎn)懸念.

Q8：如何設(shè)置主從數(shù)據(jù)庫?系統(tǒng)升級(jí)中包括 schema chang,如何保證不宕機(jī)

A8: 主從配置這個(gè)資料挺多,我就不在這里贅述了,系統(tǒng)升級(jí)這個(gè)我分享前面有介紹我們的故障切換,可以重溫下 [呲牙].

Q9: 老師請(qǐng)教一下：我們公司的私有云只提供虛擬機(jī),虛擬機(jī)里裝 mysql 這種方式可行否?

A9：虛擬機(jī)里裝 MySQL 也是 OK 的,不過需要注意的是同一宿主機(jī)的虛擬機(jī)可能會(huì)競(jìng)爭(zhēng)公共資源等等.

Q10：老師好,多實(shí)例跑在一起,如何控制資源分配,如果某一實(shí)例資源消耗過高,影響其他實(shí)例?請(qǐng)教下怎么做同一個(gè)主機(jī)室上不同實(shí)例的硬件資源調(diào)的調(diào)配?

A10: 資源隔離大家可以了解下 cgroup,磁盤配額可以使用 xfs_quota,網(wǎng)絡(luò)流量可以使用 TC.資源一般不限制,但為了避免資源爭(zhēng)用帶來的問題我們對(duì)多種硬件資源的使用進(jìn)行了監(jiān)控,一旦某硬件資源即將用盡則判定可能出現(xiàn)爭(zhēng)用問題,此時(shí)通過資源限制即可快速對(duì)對(duì)應(yīng)實(shí)例進(jìn)行限制,避免發(fā)生問題.

Q11：老師好,水平分庫是否可以做到動(dòng)態(tài)擴(kuò) / 縮容?具體怎么實(shí)現(xiàn)的?

A11: DTS+ 內(nèi)部版本 Atlas 可以做到,實(shí)現(xiàn)方式暫時(shí)不能公開,后續(xù)成熟可開源

作者介紹

劉臻,360WEB 平臺(tái)部 DBA,負(fù)責(zé)公司私有云平臺(tái) HULK 數(shù)據(jù)庫相關(guān)服務(wù)建設(shè)和數(shù)據(jù)庫服務(wù)環(huán)境基礎(chǔ)運(yùn)維.

文章來自微信公眾號(hào)：高效開發(fā)運(yùn)維

轉(zhuǎn)載請(qǐng)注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/2209.html