亚洲an日韩专区在线-亚洲an天堂an在线观看-亚洲a区视频-亚洲a图-免费黄网大全-免费黄网在线

有贊數(shù)據(jù)庫自動化運(yùn)維實(shí)踐之路

2018-01-08 16:50:28 sohu  點(diǎn)擊量: 評論 (0)
一、前言 有贊作為新零售的軟件服務(wù)供應(yīng)商,隨著業(yè)務(wù)的不斷發(fā)展,從第一批幾十家商戶到現(xiàn)在300萬商家,涉及零售,美業(yè),餐飲,自媒體等
一、前言

    有贊作為”新零售”的軟件服務(wù)供應(yīng)商,隨著業(yè)務(wù)的不斷發(fā)展,從第一批幾十家商戶到現(xiàn)在300萬商家,涉及零售,美業(yè),餐飲,自媒體等眾多商家,業(yè)務(wù)規(guī)模以及訪問量爆發(fā)式增長。

    一方面給后端數(shù)據(jù)庫帶來的影響是服務(wù)器數(shù)量和 DB 實(shí)例的數(shù)據(jù)量出現(xiàn)成倍增加。各種業(yè)務(wù)需求:快速交付實(shí)例,慢查詢優(yōu)化以及備份恢復(fù)管理等都給 DBA 的日常運(yùn)維支持帶來更高的要求。另一方面最開始以 excel 作為 CMDB 管理數(shù)據(jù)庫實(shí)例的純?nèi)巳膺\(yùn)維又給高效的數(shù)據(jù)庫運(yùn)維帶來阻礙。

    本文介紹有贊 DBA 研發(fā)的數(shù)據(jù)庫自動化管理平臺-ZanDB,解決上面的業(yè)務(wù)方發(fā)展中遇到的問題,拋磚引玉,希望能給面臨同樣需求的同行帶來幫助。

(圖1) 整體的 web 界面

二、自動化準(zhǔn)備2.1、標(biāo)準(zhǔn)化

    從事過大規(guī)模化運(yùn)維的朋友都知道:標(biāo)準(zhǔn)化是規(guī)模化,自動化的基礎(chǔ)。在我們開發(fā) MySQL 自動化運(yùn)維平臺的之前,面臨的主要問題就是各種”不標(biāo)準(zhǔn)”:OS 軟件初始化不統(tǒng)一,軟件目錄結(jié)構(gòu)不標(biāo)準(zhǔn),配置文件路徑不標(biāo)準(zhǔn),主從配置不對稱。于是我們開始著手制定標(biāo)準(zhǔn):

OS 層面

1、磁盤統(tǒng)一做成 RAID5 模式擴(kuò)大空間利用率。

2、統(tǒng)一 RAID 卡讀寫策略為 WB,IO 調(diào)度策略為 deadline,以及其他 SSD IO 方面的優(yōu)化。

數(shù)據(jù)庫層面

1、統(tǒng)一目錄配置,通過端口進(jìn)行區(qū)分,例如 my3306,my3307,在 my3306下面創(chuàng)建對應(yīng)的數(shù)據(jù)目錄、日志目錄、運(yùn)行文件目錄,tmp 目錄等。

2、每個(gè)實(shí)例獨(dú)享一個(gè)配置文件,除 server_id , innodb_buffer_pool_size 等參數(shù)外其他參數(shù)均保持一致。

3、線上環(huán)境的 MySQL 軟件目錄和版本保持一致。

    有了以上標(biāo)準(zhǔn)和規(guī)范,我們花了2個(gè)月左右的時(shí)間將以前不符合的標(biāo)準(zhǔn)的主機(jī)和實(shí)例進(jìn)行改造,并且使用 saltstack 來維護(hù) DB 服務(wù)器基礎(chǔ)的軟件安裝和文件配置規(guī)范。

2.2、ZanDB 的技術(shù)棧

    ZanDB 系統(tǒng)采用 Python Django + Percona-Toolkit + Agent(servant) + Celery+前端相關(guān)(JQuery + Ajax)技術(shù),同時(shí)利用了緩存 Redis 和 MySQL DB 作為存儲,整套系統(tǒng)采用的技術(shù)棧較簡單,實(shí)現(xiàn)的功能對于目前來說比較實(shí)用。

三、自動化運(yùn)維之路一期

    對于任何具有數(shù)據(jù)資產(chǎn)的公司而言,數(shù)據(jù)備份重于一切。由于歷史原因,有贊數(shù)據(jù)庫的備份是由 shell 腳本堆砌的,沒有統(tǒng)一的入口來查看備份結(jié)果是成功還是失敗,如果 DBA 對自己維護(hù)的數(shù)據(jù)庫的備份有效性一無所知,出現(xiàn)異常問題需要恢復(fù)而又恢復(fù)不了的時(shí)候,對有贊以及有贊的商家而言會是致命的打擊。

    因此,我們第一期的工作是開發(fā) ZanDB 備份監(jiān)控系統(tǒng)。

    它的主要功能:

1、實(shí)時(shí)查看備份的執(zhí)行情況,當(dāng)前應(yīng)備份實(shí)例個(gè)數(shù),已完成實(shí)例數(shù),備份失敗的個(gè)數(shù)。

2、顯示每個(gè)備份的耗費(fèi)時(shí)長。

3、查看過去5天的備份統(tǒng)計(jì)信息,如總個(gè)數(shù),大小等。

    完成 ZanDB 備份監(jiān)控系統(tǒng)開發(fā),我們對備份情況情況有了基本的掌握,之后開始著手設(shè)計(jì) ZanDB 的二期設(shè)計(jì)研發(fā)工作。

四、自動化運(yùn)維之路二期

    在設(shè)計(jì) ZanDB 系統(tǒng)時(shí)架構(gòu)時(shí),我們選擇使用 B/S 架構(gòu)模式,在數(shù)據(jù)庫服務(wù)器上部署我們使用 go 自研的 agent—servant,ZanDB 系統(tǒng)通過 http 服務(wù)調(diào)度 agent 執(zhí)行各種任務(wù),避免數(shù)據(jù)庫服務(wù)器通過明文密碼直連 ZanDB 的元數(shù)據(jù)庫,增加系統(tǒng)的健壯性和安全性。

    總體上我們將 ZanDB 的業(yè)務(wù)邏輯分成了七部分:元數(shù)據(jù)管理,備份管理,實(shí)例管理,主機(jī)管理,任務(wù)管理,日志管理,日常維護(hù)。

(圖2) ZanDB 系統(tǒng)設(shè)計(jì)邏輯架構(gòu)

4.1、任務(wù)系統(tǒng)

    所有的自動化管理平臺中都需要一個(gè)核心組件-任務(wù)管理系統(tǒng),主動或者被動進(jìn)行各種任務(wù)調(diào)度。我們在 ZanDB 中實(shí)現(xiàn)了一個(gè)相對健壯的任務(wù)調(diào)度系統(tǒng),用于執(zhí)行實(shí)例的備份,元數(shù)據(jù)收集,實(shí)例維護(hù)比如添加從庫,創(chuàng)建主從實(shí)例等工作, 該系統(tǒng)支持多種類型的任務(wù):支持按照時(shí)間(分鐘,小時(shí),每天,星期,月份),還支持一定間隔的重復(fù)性任務(wù)。

    該任務(wù)系統(tǒng)由數(shù)據(jù)庫服務(wù)器上的 agent-servant 和下發(fā)任務(wù)的調(diào)度邏輯構(gòu)成,任務(wù)調(diào)度的元數(shù)據(jù)表中記錄了所有的任務(wù)和任務(wù)關(guān)聯(lián)主機(jī)的時(shí)間策略。通過任務(wù)系統(tǒng),我們徹底的去掉了 DB 主機(jī)上的 crontab 腳本,動態(tài)修改任務(wù)執(zhí)行時(shí)間、策略以及是否需要執(zhí)行變得輕而易舉。

(圖3) 任務(wù)管理系統(tǒng)

4.2、備份子系統(tǒng)

    有贊的數(shù)據(jù)庫備份是利用 xtrabackup 做物理備份,經(jīng)過壓縮,然后 rsync 到備份目的機(jī)器上,定期遠(yuǎn)程備份到異地機(jī)房。在一期的基礎(chǔ)上,我們完善了備份系統(tǒng)。

1、使用 python 重構(gòu)底層備份腳本,由 db 服務(wù)器上的 agent 執(zhí)行,添加回調(diào) api 接口用于設(shè)置備份任務(wù)的運(yùn)行狀態(tài),如果一臺主機(jī)上存在備份失敗的實(shí)例,會發(fā)送報(bào)警到 DBA 的手機(jī),DBA 可以直接在備份系統(tǒng)中查看其備份報(bào)錯(cuò)日志,執(zhí)行重試,省去了登錄 DB 主機(jī)執(zhí)行的步驟。

2、和任務(wù)系統(tǒng)耦合,我們?nèi)サ袅艘黄谥幸蕾?crontab 進(jìn)行備份的定時(shí)任務(wù)。

3 、通過 ZanDB 系統(tǒng)設(shè)置備份時(shí)間以及實(shí)例是否需要備份,支持動態(tài)調(diào)整備份的目的機(jī)器。

    同時(shí),備份系統(tǒng)每天針對核心數(shù)據(jù)庫的備份執(zhí)行有效性校驗(yàn)。如果發(fā)現(xiàn)備份校驗(yàn)失敗,通過告警平臺觸發(fā)微信或者短信告警,通知 DBA 進(jìn)行檢查并進(jìn)行重新備份。

4.3、主機(jī)管理

    主機(jī)元數(shù)據(jù)是維護(hù)數(shù)據(jù)庫實(shí)例的基礎(chǔ),包含主機(jī)名,ip 地址,機(jī)房位置,內(nèi)存,空間大小等核心信息,在 ZanDB 系統(tǒng)中,我們設(shè)置了定時(shí)任務(wù)通過 Zabbix/open-falcon 的 api 獲取主機(jī)信息,比如磁盤可用空間,內(nèi)存可用空間等定期更新元數(shù)據(jù)基本信息,為分配實(shí)例提供準(zhǔn)確的數(shù)據(jù)決策。同時(shí)可以做數(shù)據(jù)庫集群數(shù)據(jù)運(yùn)營,比如預(yù)警空間剩余多少天,為數(shù)據(jù)庫集群擴(kuò)容提供數(shù)據(jù)判斷。

4.4、實(shí)例管理

(圖4) 實(shí)例管理功能

為了盡可能的發(fā)揮主機(jī)的性能,有贊的數(shù)據(jù)庫采用單機(jī)多實(shí)例的模式,主機(jī)與 DB 實(shí)例是一對多的關(guān)系。通過實(shí)例管理系統(tǒng),我們可以實(shí)現(xiàn)如下功能:

1、查看當(dāng)前的實(shí)例列表,獲取實(shí)例當(dāng)前的數(shù)據(jù)大小,日志大小,主從延遲狀態(tài),慢查個(gè)數(shù)等等。我們還可以通過實(shí)例列表設(shè)置實(shí)例是否啟用

2、新增單個(gè)實(shí)例,一對主從,添加一個(gè)或者多個(gè)從庫。新增實(shí)例的過程是通過 rsync 命令遠(yuǎn)程備份機(jī)或者本地機(jī)器上標(biāo)準(zhǔn)的數(shù)據(jù)庫模板(一個(gè)預(yù)生成且關(guān)閉的mysql實(shí)例),然后用 my.cnf 模板渲染 server_id,buffer_pool_size 等生成標(biāo)準(zhǔn) my.cnf 配置文件,執(zhí)行的具體步驟可以通過 web 界面的流程系統(tǒng)查看 ,任務(wù)調(diào)度系統(tǒng)支持部分步驟的失敗重試。

3、實(shí)例的主從一致性校驗(yàn)。在 MySQL 主從復(fù)制中,有可能因?yàn)橹鲝膹?fù)制錯(cuò)誤、主從切換或者應(yīng)用使用不當(dāng)?shù)葘?dǎo)致主從數(shù)據(jù)不一致。為了提早發(fā)現(xiàn)數(shù)據(jù)的不一致,ZanDB 每天都針對核心數(shù)據(jù)庫,進(jìn)行主從的一致性校驗(yàn),避免產(chǎn)生線上影響。

4、實(shí)例拆分,用來將之前在同一個(gè)實(shí)例里面的多個(gè) schema 拆分到不同的實(shí)例里面。

5、每天將實(shí)例的元數(shù)據(jù)進(jìn)行快照,如慢查數(shù)據(jù),數(shù)據(jù)目錄大小等,方便實(shí)例的歷史數(shù)據(jù)分析。

4.5、日志管理

    ZanDB 定義的日志管理和慢查詢有關(guān),用于維護(hù) slow_log 和 killed_sql,慢查詢?nèi)罩敬蠹叶剂私猓@里解釋一下 killed_sql。為了防止實(shí)例被慢查拖垮,我們?yōu)槊總€(gè)實(shí)例啟用類似 pt-killer 的工具 — sql-killer 進(jìn)行實(shí)時(shí)監(jiān)控,將被 kill 的 sql 寫入到具體的指定規(guī)則的日志文件中。

    大多數(shù) DBA 優(yōu)化的 SQL 路徑是登陸機(jī)器,查看慢查詢?nèi)罩荆顷憣?shí)例,獲取表結(jié)構(gòu),explain sql,檢查執(zhí)行計(jì)劃。對于規(guī)模化的 DB 運(yùn)維而言,如果只能通過登錄每臺 DB 主機(jī)才能檢查慢查詢是一件非常痛苦的事情。為了解放 DBA 的雙手,同時(shí)更好的發(fā)現(xiàn)和優(yōu)化慢日志,保障 DB 的穩(wěn)定性,ZanDB 日志系統(tǒng)由此誕生,主要做 TopN 展示和慢查分析。

    我們在收集實(shí)例元數(shù)據(jù)的過程中會去統(tǒng)計(jì)慢查和被 kill 的 SQL 的記錄數(shù)并更新到 ZanDB 的元數(shù)據(jù)中,通過頁面展示各個(gè)業(yè)務(wù)中慢查詢最多的 topN。當(dāng)然我們也設(shè)定慢查詢報(bào)警閾值,慢查詢超過一定閾值的實(shí)例會觸發(fā)短信報(bào)警,及時(shí)通知 DBA 和開發(fā)關(guān)注。

(圖5) 慢查詢系統(tǒng)

    有了慢查詢的數(shù)據(jù)之后如何解決”不在登陸主機(jī)查看慢查 sql”呢?我們的系統(tǒng)每天會將慢查詢?nèi)罩咀鲚嗈D(zhuǎn)切割,每天產(chǎn)生一個(gè)日志文件,ZanDB 通過 agent 調(diào)用 pt-query-digest 分析指定的慢查日志并返回給 ZanDB 的頁面端,展示表結(jié)構(gòu),慢 sql ,對應(yīng)的執(zhí)行計(jì)劃,以及表的大小信息。

    系統(tǒng)要獲取慢查詳情的時(shí)候,通過調(diào)用 pt-query-digest,分析慢日志文件,先將結(jié)果存到對應(yīng)的實(shí)例 slow log 里,系統(tǒng)下次再獲取慢查的時(shí)候,如果發(fā)現(xiàn)該日期的慢查已經(jīng)存在分析后的結(jié)果,直接返回。同時(shí),日志管理里面還包含了被 kill 的 SQL 的 top 情況,和慢查是類似的。

4.6、元數(shù)據(jù)管理

(圖6) 分片信息查詢

    元數(shù)據(jù)管理包含了 binlog 元數(shù)據(jù)、主鍵的溢出校驗(yàn),分片信息信息等。

    binlog 元數(shù)據(jù)管理主要記錄每個(gè)實(shí)例的每個(gè) binlog 起始時(shí)間和結(jié)束時(shí)間,binlog 保留時(shí)長,在進(jìn)行數(shù)據(jù)恢復(fù)的時(shí)候可以快速的定位到某個(gè)日志。

    通過主鍵溢出校驗(yàn),我們可以及時(shí)的發(fā)現(xiàn)哪些表的主鍵自增已經(jīng)達(dá)到了臨界值,避免因主鍵自增溢出無法插入導(dǎo)致故障。

    由于我們商品,交易等核心庫是分庫的,分析慢查,問題定位的時(shí)候,需要根據(jù)分片鍵找到對應(yīng)的實(shí)例 ip:port。我們開發(fā)了一個(gè)分片元數(shù)據(jù)查詢功能,只要提供數(shù)據(jù)庫名,表名,分片鍵,就可以快速的定位到一個(gè)實(shí)例,減少之前人工計(jì)算的過程。

4.7、日常維護(hù)

(圖7) 日常維護(hù)功能界面

    日常維護(hù)主要是解決部分低頻但是耗時(shí)的人肉操作,批量查看實(shí)例的某些參數(shù),批量修改配置,緊急的 binlog 恢復(fù)等。

    批量執(zhí)行 SQL 是選擇一批實(shí)例,執(zhí)行維護(hù)的 SQL。例如,需要修改內(nèi)存中某個(gè)參數(shù)的值,或者獲取參數(shù)的值。這個(gè) SQL 只允許維護(hù)相關(guān)的,DML 是不允許執(zhí)行的。

    批量修改配置和執(zhí)行 SQL 類型的修改配置類似,不同的是,修改配置是會同步變更配置文件,永久生效,同時(shí)也修改內(nèi)存,例如調(diào)整慢查時(shí)間等。

    解析 binlog 是基于開源的 binlog2sql 做的,根據(jù)提供的數(shù)據(jù)庫名稱,表名,時(shí)間段,利用binlog 元數(shù)據(jù)查到指定的 binlog 進(jìn)行解析得到文本文件 可以在網(wǎng)頁查看和下載,在解決突發(fā)的開發(fā)誤操作需要緊急恢復(fù)過程中特別有效。

4.8、數(shù)據(jù)運(yùn)營

    ZanDB 從開發(fā)落地到現(xiàn)在已經(jīng)半年多時(shí)間了,積累了一定量的實(shí)例數(shù)據(jù)空間大小,內(nèi)存大小等,我們利用這些積累的數(shù)據(jù)做運(yùn)營分析,開發(fā)了趨勢圖和成本核算功能。

    趨勢圖用于展示數(shù)據(jù)庫總體的空間和內(nèi)存利用率情況,以及核心業(yè)務(wù)的增長曲線,方便 dba 對機(jī)器資源進(jìn)行調(diào)配。

    成本核算功能統(tǒng)計(jì)各個(gè)業(yè)務(wù)耗費(fèi)的成本以及占用比例,為業(yè)務(wù)層決策提供一定的參考。

4.9、HA 管理

    有贊的數(shù)據(jù)庫高可用經(jīng)歷了兩個(gè)階段。

    第一個(gè)階段是基于 keepalived + vip 架構(gòu)的 HA,但是我們也遇到了磁盤 io 抖動導(dǎo)致腳本檢查失敗切換和基礎(chǔ)網(wǎng)絡(luò) arp 廣播限速導(dǎo)致 ha 切換失效的問題。這種方式也不可避免的會有腦裂問題。

    第二階段我們自研了基于 go 語言的HA管理工具 hamster。hamster 有強(qiáng)大的集群管理能力,可以同時(shí)維護(hù)大量 MySQL 集群,進(jìn)行健康檢查,故障切換,主動切換,狀態(tài)監(jiān)控。提供了完整的 Restful API 來管理集群和實(shí)例。

    在高可用方面,總體原理上類似 MHA。實(shí)現(xiàn)了基于 relay log 解析和基于 GTID 兩種方式來處理 MySQL 故障切換時(shí)的數(shù)據(jù)填補(bǔ)問題。主動切換和故障切換通常在秒級時(shí)間內(nèi)就能完成。高可用體系還結(jié)合了我們的 proxy 來控制客戶端訪問。數(shù)據(jù)庫切換不再使用 vip,避免了之前的 arp 導(dǎo)致的切換失效,也不再受 arp 不能跨網(wǎng)絡(luò)的限制,為實(shí)現(xiàn)有贊 IT 基礎(chǔ)架構(gòu)雙機(jī)房容災(zāi)打下基礎(chǔ)。

五、展望

    目前開發(fā)完成的 ZanDB 系統(tǒng)能夠解決70%左右的人肉運(yùn)維工作,但是距離完全的自動化還是有一定的差距,后續(xù)在運(yùn)維方面還需要實(shí)現(xiàn)秒級監(jiān)控,日志審計(jì),實(shí)例巡檢,實(shí)例水平拆分等功能,面向開發(fā)方面需要完善數(shù)據(jù)庫性能診斷,自動分析數(shù)據(jù)庫慢查等功能。

    從用戶使用交互來看,現(xiàn)在的 ZanDB 更多的是給 DBA 用的,但是系統(tǒng)最終服務(wù)的對象是業(yè)務(wù)方或者開發(fā),如何提高系統(tǒng)的有效使用率,在交付和維護(hù)使用上給開發(fā)帶來收益也是我們要思考和落地的目標(biāo)。

    最后,有贊的業(yè)務(wù)正在快速發(fā)展,我們要走的路還很長,這路上挑戰(zhàn)與機(jī)遇并存,我們需要更多優(yōu)秀的運(yùn)維人才加入有贊,和我們一起構(gòu)建穩(wěn)定,高效的IT基礎(chǔ)設(shè)施。

大云網(wǎng)官方微信售電那點(diǎn)事兒

責(zé)任編輯:售電衡衡

免責(zé)聲明:本文僅代表作者個(gè)人觀點(diǎn),與本站無關(guān)。其原創(chuàng)性以及文中陳述文字和內(nèi)容未經(jīng)本站證實(shí),對本文以及其中全部或者部分內(nèi)容、文字的真實(shí)性、完整性、及時(shí)性本站不作任何保證或承諾,請讀者僅作參考,并請自行核實(shí)相關(guān)內(nèi)容。
我要收藏
個(gè)贊
?
主站蜘蛛池模板: 99热久久精品国产 | 沈樵在线观看福利 | 亚洲精品一区二区在线播放 | 欧美日韩偷拍自拍 | 日本草草影院 | 久久精品男人的天堂 | 日本免费观看的视频在线 | 国产精品自在欧美一区 | 国产一级精品毛片 | 萌白酱喷水福利视频在线 | 在线观看亚洲视频 | 久久久久久亚洲精品不卡 | 日韩日韩日韩手机看片自拍 | 亚洲美女福利视频在线 | 在线观看一区二区三区视频 | 亚洲女人网 | 久久99国产精品久久99果冻传媒 | 18video9ex欧美生活片 | 韩国免又爽又刺激激情视频 | 能看毛片的网址 | 国产高清精品自在线看 | 欧洲一级毛片免费 | 加勒比色久综合在线 | 美女黄色在线看 | 欧美性色黄在线视 | 欧美午夜网站 | 手机看片国产日韩 | 理论片中文字幕 | 大伊香蕉精品视频在线观看 | 一区二区三区视频观看 | 欧美精品日本一级特黄 | 欧美a级在线观看 | 失禁h啪肉尿出来高h男男 | 日韩在线视频免费不卡一区 | 91精品国产综合久久青草 | 国产欧美日韩在线观看一区二区三区 | 日韩欧美视频在线播放 | 欧美日韩亚洲国产精品 | 欧美一区二区三区男人的天堂 | 国产精品久久久久久久久久直 | 久久精品国产亚洲精品2020 |