京東數(shù)科大促運維實踐

1、京東數(shù)科大促運維實踐技術(shù)創(chuàng)新 變革未來PART01運維概述PART02備戰(zhàn)準備PART03大促進行時PART04案例復盤DBA團隊數(shù)據(jù)庫運維架構(gòu)搭建、性能優(yōu)化、故障排查、安全防 護、備份與恢復、部署與下線、變更查詢自動化智能化運維產(chǎn)品運維平臺、性能診斷平臺、數(shù)據(jù)查詢平臺、 數(shù)據(jù)建模平臺、數(shù)據(jù)復制平臺、數(shù)據(jù)庫變 更平臺、歸檔平臺、數(shù)據(jù)庫中間件科技輸出分布式事務數(shù)據(jù)庫、自動化運維產(chǎn)品、數(shù) 據(jù)庫解決方案、私有云運維目標海量數(shù)據(jù)架構(gòu)轉(zhuǎn)型服務可用率數(shù)據(jù)安全水平拆分數(shù)據(jù)服務1、DB數(shù)據(jù)容量大2、每日增量快速3、多模數(shù)據(jù)存儲4、字段和數(shù)據(jù)變更慢1、業(yè)務發(fā)展催生架構(gòu) 轉(zhuǎn)型2、性能瓶頸尋求架構(gòu) 變革3、成本和安

2、全優(yōu)化促 進轉(zhuǎn)型1、故障風險分攤2、高可用方案，可用 率保障3、合規(guī)要求，多數(shù)據(jù) 中心技術(shù)保障1、數(shù)據(jù)一致性2、事務一致性3、安全加固方案4、備份策略1、對業(yè)務透明、 研發(fā)改動小2、數(shù)據(jù)均勻分布， 風險分攤3、二次縮擴容4、分布式事務1、運營報表類聚 合查詢2、數(shù)據(jù)遷移同步 能力和效率性能保障1、慢查詢2、TPSQPS3、連接數(shù)持續(xù)規(guī)范價值服務精細保障高效運維體系核心目標數(shù)據(jù)一致性容災可用性安全合規(guī)管控運維自動化數(shù)據(jù)治理應用層中間層數(shù)據(jù)庫層大數(shù)據(jù)層運維組件產(chǎn)品數(shù)據(jù)建模平臺DBCM數(shù)據(jù)庫中間件CDS、SS數(shù)據(jù)庫運維管理系統(tǒng) Mega數(shù)據(jù)庫性能展示平臺 CleverDB數(shù)據(jù)復制平臺DBRep業(yè)務層

3、級業(yè)務需求資源管控自動部署HA切換資源回收備份恢復任務調(diào)度DB遷移數(shù)據(jù)接口空間分析會話分析性能分析慢查詢分析數(shù)據(jù)抽取復制訂閱水平拆分讀寫分離彈性擴容分布式事務SQL自助建模SQL自助查詢SQL自助變更查詢機MyDB工單流程平臺MagicFlow大數(shù)據(jù)計算與分析平臺備戰(zhàn)準備案例復盤大促進行時備戰(zhàn)巡檢容量評估優(yōu)化改造數(shù)據(jù)歸檔壓力測試切換演練變更管控大促調(diào)整監(jiān)控大屏應急處理事件管理案例分享經(jīng)驗總結(jié)表分區(qū)Top SQL連接數(shù)定時調(diào)度業(yè)務梳理自增主鍵單表21億 全局自增主鍵備份時間維度的分區(qū) 時間維度的拆分活躍連接數(shù) max_connectionsSQL 頻次SQL 效率備份作業(yè) 有效性檢查慢查詢SQL

4、 消耗 優(yōu)化改造硬件&機房磁盤Raid卡出口帶寬 機柜超電 雙電鏈路溫濕度數(shù)據(jù)庫依賴程度 事務讀寫邏輯上下游調(diào)用邏輯磁盤空間熱點表容量評估系統(tǒng)相關(guān)DB相關(guān)數(shù)據(jù)量大 拆分不均勻 影子表硬件容量 性能容量備戰(zhàn)巡檢業(yè)務跑批 ETL抽取 信息采集 備份調(diào)度巡檢通道 - CleverDB參數(shù)評分第一檔第二檔第三檔第四檔權(quán)重SQL質(zhì)量QPS容量（CPU）qps/cpu_perce nt015001500500050008000800099999910QPS容量（IO）qps/io_percent03000300060006000100001000099999910TPS容量（IO）tps/io_perce

5、nt010001000300030005000500099999910參數(shù)評分第一檔第二檔第三檔第四檔第五檔權(quán)重資源利用率CPU使用率cpu_percent60100053060515153015IO使用率io_percent8010001050801025255015磁盤利用率磁盤使用率disk_percent80100055080515155030容量評估l評分計算說明QPS容量（CPU）：根據(jù)峰值QPS和CPU使用率得到的理論QPS最大值， 可以體現(xiàn)查詢操作對CPU計算資源的使用效率。QPS容量（IO）：根據(jù)峰值QPS和IO使用率得到的理論QPS最大值，可以 體現(xiàn)查詢操作對磁盤數(shù)據(jù)的訪問

6、率。TPS容量（IO）：根據(jù)峰值TPS和IO使用率得到的理論TPS最大值，可以 體現(xiàn)變更語句對IO資源的使用效率。CPU使用率：峰值CPU使用率百分比。IO使用率：峰值IO使用率百分比。磁盤使用率：最大磁盤使用量百分比。主庫權(quán)重為1，從庫權(quán)重0.3容量評估容量評估50%100%分數(shù)0%50%100%30%70%分數(shù)縮容擴容歸檔縮容優(yōu)化、擴容讀寫分離磁盤使用率CPU使用率0% 5%10% 20%30%容量評估選型多實例單實例CDS orSS容量1SQL優(yōu)化SQL采集、執(zhí)行計劃、sql解析、統(tǒng)計分析、索引優(yōu)化、優(yōu)化推薦2配置優(yōu)化模板固化、動態(tài)調(diào)整、變更流程（連接）3數(shù)據(jù)優(yōu)化歸檔、冷熱數(shù)據(jù)、表結(jié)構(gòu)4

7、架構(gòu)優(yōu)化r2m、Hcenter、 MQ、硬件擴容代碼優(yōu)化 邏輯、事務、降級開關(guān)5優(yōu)化改造數(shù)據(jù)同步冷備份數(shù)據(jù)管道dbrep主從同步縮擴容流程容量評估QPS/TPSCPU/DISK/MEM歷史增長率硬件配置資源評估硬件需求數(shù)量預期增長量預算情況峰值預估遷移方案提高硬件配置（切換）多庫架構(gòu)拆分（垂直）單庫多表拆分（垂直）單表拆分（水平）資源申請工單系統(tǒng)申請DB環(huán)境初始化代碼邏輯改造測試環(huán)境驗證數(shù)據(jù)校驗權(quán)限校驗網(wǎng)絡(luò)校驗一致性校驗切分規(guī)則校驗切換遷移Online切換（透明）修改連接池（集群）dnsvip調(diào)整（重啟）舊資源回收下線容量評估QPS/TPSCPU/DISK/MEM歷史增長率硬件配置遷移方案DB

8、下線（工單回收）降低硬件配置（切換）單庫多表拆分（垂直）水平拆分+hdb資源申請工單系統(tǒng)申請DB環(huán)境初始化代碼邏輯改造測試環(huán)境驗證擴容縮容數(shù)據(jù)歸檔3冷熱數(shù)據(jù)劃分歸檔條件篩選歸檔時間節(jié)點和頻率歸檔數(shù)據(jù)訪問規(guī)則歸檔規(guī)則數(shù)據(jù)歸檔結(jié)轉(zhuǎn)對性能影響的追蹤結(jié)轉(zhuǎn)效率的評估數(shù)據(jù)刪除機器級別實例級別庫級別表級別空間分析1、備份刪除2、歷史表3、歸檔庫4、大數(shù)據(jù)平臺應用緩存 DB API壓力測試切換演練遷移前溝通+公告 搭建從庫 一致性檢查 HAcheck 應用check 網(wǎng)絡(luò)check遷移中原主庫只讀變更指向或vip漂移 訪問流量check研發(fā)check 新主庫讀寫 元數(shù)據(jù)變更遷移后去除復制關(guān)系 備份策略調(diào)整 資

9、源回收下線提升團隊協(xié)作能力檢查高可用系統(tǒng)提升團隊應急處理能力研發(fā)DBA變更管控核心業(yè)務數(shù)據(jù)一致性 備份恢復時間長任務跑批無法完成降低IO消 耗調(diào)整后的代價大促調(diào)整監(jiān)控大盤監(jiān)控大盤監(jiān)控大盤應急預案硬件故障 主庫容災方案 從庫容災方案 機房容災方案鏈路故障 連接數(shù)滿 權(quán)限 防火墻端口 讀寫分離 網(wǎng)絡(luò)抖動性能故障 慢查詢 帶寬流量 事務鎖 事務未提交服務組件故障 監(jiān)控故障 計算平臺故障事件標題事件管理發(fā)生時間響應時間解決時間影響范圍負責人事件原因事件描述事件等級部門歸屬解決方案、改進項：1、2、3、4、5。業(yè)務架構(gòu)運維安全合規(guī)持續(xù)追蹤案例分享一故障描述：業(yè)務主庫寫入性能下降故障原因：讀寫分離，15個

10、從庫，多個從 庫獲取主庫binlog，導致主庫推送binlog 時系統(tǒng)上下文切換頻繁，負載升高，寫性能 下降。解決方法：關(guān)閉多個從庫案例分享一1、從庫擴容超過5個，使用級聯(lián)復制，或者使用dbrep復制2、從庫擴容后，都要進行性能壓測，驗證擴容合理性3、自動識別Sending binlog event to slave 過多的現(xiàn)象4、實現(xiàn)自愈，下掉從庫以及保障從庫高可用5、資源擴容要有從庫數(shù)量提醒6、接口應用增加容錯機制，可自動降級案例分享二故障描述：業(yè)務從庫異常重啟故障原因：DBA開啟半同步時，正處于某事務在binary log group commit的flush階段， 會觸發(fā)bug,導致M

11、ySQL重啟解決方法：升級版本2019-06-1823:45:361015NoteSemi-syncreplicationswitched OFF.2019-06-1823:45:361015NoteSemi-syncreplicationdisabled on the master.2019-06-1900:18:251015NoteSemi-syncreplicationinitialized for transactions.2019-06-1900:18:251015NoteSemi-syncreplicationenabled on the master.mysqld: /mysql

12、-5.6.26/plugin/semisync/semisync_master.cc:792: int ReplSemiSyncMaster:commitTrx(const char*, my_off_t): Assertion entry failed. 16:08:25 UTC - mysqld got signal 6 ;案例分享二Commit Stage將每個事務寫入binlog緩存中將binlog緩存內(nèi)容刷到磁盤根據(jù)順序調(diào)用存儲引擎提交事務Semi sync 會通過activetransaction這hash表，記錄提 交事務的name、pos和entry 標識，緩存這些信息的目的是

13、 在發(fā)送binlog時判斷要不要等 從庫返回的ACK。這個entry的 意義就是告訴從庫這個event需 要返回ACK設(shè)置binlog的相對位置 trx_wait_binlog_name trx_wait_binlog_pos當從庫返回ACK時，會和wait的pos 進行對比，如果比wait的值大于等于 就提交，否則等待rpl_semi_sync_master_enabled=on當事務已經(jīng)處于flush階段，但半 同步?jīng)]有打開，此時entry 標識 沒有生成dump進程已經(jīng)發(fā)送事務給從庫,主 庫在等待從庫返回ACK時出現(xiàn)了 assertion failure如果是after_commit 則對比的邏輯在coommit 階段進行。Bug fix之前