《360 私有云平臺 MySQL 自動化實現剖析》要點：
本文介紹了360 私有云平臺 MySQL 自動化實現剖析，希望對您有用。如果有疑問，可以聯系我們。

HULK 私有云平臺 MySQL 服務剖析 — MySQL 自動化在 HULK 中的實現, 這次的分享題目是：HULK 私有云平臺 MySQL 服務剖析 — MySQL 自動化在 HULK 中的實現.本次分享主要從下面幾個方面來介紹：

1. HULK 私有云平臺介紹
2. 現有 MySQL 服務規模
3. MySQL 服務常用功能展示
4. 各功能模塊設計實現思路
5. 新的計劃

現狀 & 服務規模

說起 HULK 私有云平臺大家有參加過之前我們同事分享的應該聽過,360HULK 私有云平臺是奇虎 360 公司內部專屬私有云平臺,平臺涉及云計算、數據庫、大數據、監控等眾多技術領域.今天要分享的 MySQL 服務就是 HULK 數據庫服務中的一種.

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

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

實現全部自動化后,業務可以隨時隨地自助的提交數據庫申請,不受時間和外部其他因素困擾,并能快速的投入使用,極大的提高了開發效率.

各功能模塊設計實現思路

下面會根據業務在 HULK 上從申請到最終下線,貫串整個流程來演示和分析下各個模塊的功能和設計思路.

創建實例 ?

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

而要做到這樣的全自動,就需要從資源分析控制上入手,怎么合理的分配資源,且能高效的利用,是重點要考慮的問題,下面是我們在做自動化中遇到和解決的幾個技術點：

借鑒各個公有云的模式,我們分析了業務的各種需求類型,同時對比我們內部的數據庫資源,將數據庫實例歸類劃分為套餐,不同的套餐對應不同的數據庫資源,每臺服務器也有自己對應的資源總數,實例新建、擴容、下線等都會相應增刪不同比例的資源.這樣每臺服務器理論分配的數據庫實例和對應消耗的資源是可控的.

同時,我們對服務器實際消耗的資源進行動態統計分析,并對健康狀態進行打分,這樣進一步來控制服務器的資源使用.

自動關聯監控系統比不可少,第一時間將數據庫實例納入監控體系,并且在管理員維護操作的時候可以靈活啟停監控.

對機器資源統計方面我們重點監測下面 7 個點,有一個監測點的值超過了對應閾值則處于不同的狀態,在創建實例自動選擇機器的時候,將會按照不同的邏輯選擇.

數據庫架構 & 高可用

實例創建完成,下圖是我們默認的數據庫架構圖,以雙 IDC 為例,用 Atlas 作為中間層,提供讀寫分離,Atlas 已經開源具體可以參考：https://github.com/Qihoo360/Atlas . 在 Atlas 之上用 LVS 做了一次隔離和負載均衡,其中為了高可用,每個機房的服務節點都是部署多個,避免單點故障.

當單個 Atlas 故障的時候,LVS 檢測到異常會直接下線,而當單個從庫故障的時候,Atlas 檢測到也會下線. 這樣在 Atlas 和從庫單點故障的時候整個集群還能正常工作,并且不影響業務使用.但是,當主庫掛掉的時候,就改我們的故障自動切換 Failover 出場了.

下圖是我們主庫宕機時的切換流程,我們的故障切換服務 MySQL Failover 實時監控集群狀態,當發現主庫宕機后,會根據選主邏輯選出新主庫、補全數據、重做主從結構然后修改 Atlas 的配置,到此整個切換流程完成,MySQL Failover 重新進入監控狀態.正常情況整個故障切換耗時 15s 左右.

建表改表 ?

說完數據庫結構和故障切換,按照正常操作流程業務們該建表、改表、授權、查看監控等操作了,其中授權監控這里就不多贅述了.因為我們平臺默認給業務方只有對數據的增刪改查權限,所以建表改表需要業務來 HULK 平臺操作,針對建表,我們根據運維經驗和踩坑實踐,總結了 16 個檢查項,這里貼出來和大家分享下.

建表語句需要符合一定標準,否則將建表失敗,具體審核標準如下：

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

下面這個是測試建表的示例.

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

測試環境 ?

為了方便業務測試,我們在平臺上提供了測試環境,并且將測試環境和線上環境打通,業務可以直接將庫表結構在線上和測試之間互導.方便業務測試和上線操作.

優化建議 ?

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

未使用索引我們使用了 MySQL5.6 中 PS 庫的 table_io_waits_summary_by_index_usage 表的信息,匯總分析出沒有被使用到的索引,重復索引會浪費存儲空間,同時對數據更新性能也有影響,在一些場景下,還會對查詢優化器造成干擾,可謂百害而無一利.

我們另一個優化建議就是 char 字段優化了,好多業務在建表的時候喜歡用 char 類型,但是 char 是固定長度,申請多少就占多少空間,當存入的字符串長度不夠的時候會用空格補齊,這樣在非定長的字符串存儲中 char 會浪費大量的存儲空間,所以我們對線上的所有字段定期進行分析匯總,掃描出使用長度遠小于申請長度的表和字段,以報表的方式展示給業務,方便業務及時優化,我們建議直接將 char 改為 varchar,除非存儲的是定長的比如 md5 之類的字符串,否則全部建議用 varchar.varchar 是可變長度的,實際使用多少就分配多少,額外再用 1-2 字節存儲長度,并且超過指定長度還可以繼續寫入.

數據恢復 ?

大家關心的數據恢復來了,不知道大家有沒有這個經歷：不小心誤操作了需要恢復數據,但是聯系 DBA、溝通需求、DBA 數據恢復、業務數據確認、替換上線,這整個流程走下來可能影響已經擴大,況且有可能數據恢復的需求在半夜,這個流程可能又延長很多.出于這種場景的考慮,我們將數據恢復也做成了自動化的任務,業務可以自助隨時提交恢復任務,避免溝通確認各個環節浪費寶貴的數據恢復時間.數據可以恢復到 7 天以內任意時間點.看操作流程截圖：

業務之需選擇需要恢復的庫表,選擇時間提交任務即可,視數據量大小耗費時間不一,普通的幾 G 的數據表,一般分鐘級就能恢復,恢復后會生成臨時實例,業務去臨時實例確認數據無誤后就可以一鍵替換線上,完成數據恢復申請.

數據備份

前面大家也了解了自動數據恢復,數據恢復依賴于完善的數據備份.我們的備份系統各模塊構成如下圖：

備份系統特點

多維度備份

全量備份 + 增量備份(binlog),每天都會進行全量備份,同時實時進行 binlog 備份.

合理的保留策略

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

?自動更新備份策略

策略根據當天狀態動態刷新,根據從庫狀態(我們在從庫備份),存儲狀態,網絡狀態等動態跟新備份策略.

?失敗檢測預警

備份失敗自動歸類,集中處理.備份失敗檢測模塊會將失敗任務匯總,報表展示.

?過期自動清理

存儲管理模塊會根據保留策略,清理過期的備份數據.

我們備份系統是基于 Percona XtraBackup 實現的,不過根據我們的使用場景,做了一些改進與提升：

?分庫分表獨立備份壓縮

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

改造支持單 / 多表恢復

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

支持數據加密和加密傳輸

增加了數據加密模塊和加密傳輸模塊

?增加多種恢復模式

支持時間點,binlog_pos,sql 等多種恢復模式

從 DBA 和運維角度出發,還可以做一些事情來避免機器級別的故障：

1. 關注遠控報錯,有問題及時遷移實例報修
2. 監控系統日志,提前發現故障機器.有一些硬件故障不會導致立即宕機,單是個定時炸彈,這些信息會被記錄到系統日志,如 message,mcelog 中,對這些日志增加監控,可以提前發現有故障隱患的機器,提前遷移數據庫實例,避免宕機影響服務.
3. 控制機器過比率,發現現在廠商對過保故障控制的特別到位,一過保,機器故障率里面飆升,所以我們也對機器的過保情況進行了統計,避免重點業務部署在已過保的機器上.

新的計劃

日常操作自動化之后,業務開發效率提高同時 DBA 也可以省去之前大量的重復勞動,可以有更多的精力來提高服務質量以及研究寫新的技術.以上就是我們 HULK 平臺 MySQL 服務的一些設計思路和實踐經驗.

QA 環節

Q1：未來計劃的數據庫的遷庫操作是怎樣的?是不是開發人員可以很簡單地進行操作?

A1：數據遷移是想實現從自建的或者非標準的數據源將數據遷移到我們標準的平臺上來,并且盡量不影響源數據庫的使用.計劃是做成一個通用服務,業務人員之需填寫數據源和目的的相關配置即可.

Q2: 能詳細說明一下 dts 實現當時么,尤其對于大數據庫?

A2: DTS 還在開發中,后面有機會和大家交流.

Q3: 請問你們有做 SQL 操作日志審計嗎,是如何撲獲 MySQL 執行的所有 sql 語句的?

A3: 我們全量的 SQL 日志是通過 Atlas 收集匯總的,上面也有放 Atlas 的 github 連接,感興趣的同學可以去看看.

Q4：辛苦了!測試環境和線上環境的打通是怎樣做到的,Docker 嗎?

A4: 我們這邊在 HULK 平臺上通過業務的方式來關聯服務,同一個業務可以在自己的線上環境和測試環境之間做遷移,DBA 這邊直接通過管理賬號后臺打通權限.

Q5: 請問數據庫實例是安裝在哪里呢, 一臺物理機如何部署多個 mysql 實例?

A5: 數據庫實例是部署在物理機上的,一臺物理機部署多個 MySQL 實例,可以配置多個配置文件,設置不同的數據目錄即可.

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

A6: 這個得根據實際情況來分析,現在硬件性能提升很快,不分片也能抗很大的請求,具體分片需要根據實際的數據量、訪問量、瞬間并發量、機器性能等等來設計.

Q7：“其中數據庫服務又集合了 MySQL、Redis、Mongodb、Greenplum、ElasticSearch 等”,請問能否介紹下各類數據庫的應用情況?

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

Q8：如何設置主從數據庫?系統升級中包括 schema chang,如何保證不宕機

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

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

A9：虛擬機里裝 MySQL 也是 OK 的,不過需要注意的是同一宿主機的虛擬機可能會競爭公共資源等等.

Q10：老師好,多實例跑在一起,如何控制資源分配,如果某一實例資源消耗過高,影響其他實例?請教下怎么做同一個主機室上不同實例的硬件資源調的調配?

A10: 資源隔離大家可以了解下 cgroup,磁盤配額可以使用 xfs_quota,網絡流量可以使用 TC.資源一般不限制,但為了避免資源爭用帶來的問題我們對多種硬件資源的使用進行了監控,一旦某硬件資源即將用盡則判定可能出現爭用問題,此時通過資源限制即可快速對對應實例進行限制,避免發生問題.

Q11：老師好,水平分庫是否可以做到動態擴 / 縮容?具體怎么實現的?

A11: DTS+ 內部版本 Atlas 可以做到,實現方式暫時不能公開,后續成熟可開源

作者介紹

劉臻,360WEB 平臺部 DBA,負責公司私有云平臺 HULK 數據庫相關服務建設和數據庫服務環境基礎運維.

文章來自微信公眾號：高效開發運維

轉載請注明本頁網址：
http://www.snjht.com/jiaocheng/2209.html