转 当当网资深DBA：DB运维四大现代化的实现
位好，今天我的主題是 《DB運維的四個現代化》 ，看標題就能明白，是關于DBA自動化運維平臺的事情。
http://dbaplus.cn/news-21-855-1.html
?
主要是分享下我在當當想到做到的一些事情，很多都是兄弟們一起努力的結果， 這篇文章也是對我們工作進行一次總結，整個平臺的實現方法并沒有用到什么高大上的框架，有亮點的地方我會著重說明，當然，有興趣了解的同學，直接提問就好。
?
本次分享將分為以下三部分進行：
??? 解密DB管理四大現代化
??? 實例分析實踐痛點
??? 從信息展現開始一步步解決
?
一DB管理四大現代化
?
首先先聊下DB在項目中的地位：
?
?
??? 99%的軟件，處理的數據最終是需要落地
??? 從人員結構來說，DBA支持公司多項目
??? 數據要安全，數據要及時，權限要收口
?
于是，DBA的工作經常成為項目進展的瓶頸。
?
然而，在錯綜復雜的電商環境中， 數據庫又獨具特色。一提到電商： 自然想到，雙11，秒殺，大促等等，?? 于是下面3個特點也就不言而喻。
?
?
在當當網，我們的DB規模是這樣的，數據截止到2016年3月，而現在又在增長……T_T
?
?
因此就會有這樣的工作需求：
??? 商品單品項目組、新來的開發同學，需要了解單品項目的表設計結構；
??? 購物車項目管理的同學需要同步最新數據，檢查項目運行效果；
??? 訂單項目的同學需要檢查實時數據，監控訂單量（授權給radar監控數據源）；
??? 測試的同學需要檢查回歸測試的數據效果。
?
二實例分析實踐痛點
?
商品分類項目程序出現了bug，導致分類錯誤， 最有效的辦法莫過于：DB中需要修改幾條數據。
?
??? 項目擴容，需要部署從庫，項目遷移，需要切換到從庫；
??? 硬件故障，需要切換；
??? 所有項目大大小小 500+個DB實例?? (ﾉﾟ⊿ﾟ)ﾉ? So，不理想的狀態下， 以上工作×500倍；
??? DBA負責按工單導出數據，工單多了就放開查詢權限，
??? 人員流動(←_←)，于是一堆不明權限，數據安全無法保證。
?
于是，DBA們也在思考，和開發項目拼人肉數目，肯定不切實際，我們需要自動化的平臺。
?
根據以上問題，我們做了幾個選擇：
??? 哪些信息是可以共享給開發部門的。
??? 哪些操作DBA可以自動，符合標準的進行。
??? 用什么方法盡可能保證數據的實時準確性
?
用下圖來回答：
?
?
平臺主要分為：信息收集展現，DBA管理工具兩大部分。
?
數據庫的元數據可以被全體技術部乃至業務部訪問。但數據細節，只能有限訪問（權限申請需要經過審批）這些只讀的訪問，一次授權，即可自助進行。
?
對于數據庫管理（部署，備份，恢復），DBA也要編寫腳本，按標準進行。后面會盡量詳細介紹。
?
三從信息展現開始一步步解決
?
1、信息收集展現
?
先說明下，關于數據庫元數據的展現：
?
?
上圖可見，借用phpmyadmin工具(右圖)，對于元數據的展現還是很完美的。完全可以替代左圖的命令行模式。
?
當然，這里的phpmyadmin是經過修剪功能的版本，去掉了諸多管理，展示數據細節的部分。
?
對于申請過權限的用戶，才可以訪問到受限的數據細節。
?
同時對于數據本身，也進行了限制性修改 ，僅能訪問 500行的數據：
?
?
對于元數據也進行了抓取和歸檔(主要用shell+python定時執行 實現)，這樣做有幾個好處：
?
1、便于在整個公司項目范圍內，宏觀的、快速的、模糊的查找想要的元數據。
2、基于元數據的定期歸檔，可得出數據空間變化的規律。
?
例如我們平臺的如下功能：
?
?
?
?
3、還可以對元數據進行統計，迅速得出那些是我們急需調優的目標（需水平拆分的大表，需垂直拆分的寬表，需要刪除的重復索引，需要擴容的autoid等等）。
?
例如，我們平臺的如下功能：
?
? ?
?
展示出來就是這樣（圖表展示我采用highchart，MySQL只負責用SQL吐數據，展示的活，就交給highchart 了）：
?
?
?
4、管理服務器列表，對于所有服務器的固定端口(數據庫端口)進行掃描，及登陸測試，獲取庫名，角色(主or從)，等信息。
?
?
對于性能和監控數據，采用同樣的方法進行抓取和分析，(數據源取自zabbix監控數據庫)
?
這樣做的好處是：
??? 看出近期那些性能指標頻繁報警，需要擴容，需要調優
??? 那些服務器是重載，那些卻過分規劃即使大促也是輕載。
?
?
(上圖屏蔽的主要是一些ip和庫名信息.)
?
2、DBA管理工具
?
這部分我們也在進行中，目前DB的安裝/部署的基本已經實現腳本化，主要包括下面的腳本。
?
?
下面是部分腳本的功能說明：
?
?
該腳本的主要功能：
??? 根據標準初始化完成的系統，自動安裝相關軟件包，備份時部署在集群的從庫，且無域名的從庫優先，
??? 關于備份空間的判斷，先根據數據量估算本次備份所需空間，如果備份空間滿足，則備份到該從庫的本地，如果不滿足則集中備份到大空間服務器。
?
備份會保留多個備份周期的備份集. 如空間吃緊，備份前，則會優先刪除日期靠前的備份集。
?
?
該腳本的主要功能：
??? 初始化MySQL時候生成環境檢查
??? 根據內存大小動態計算buffer pool大小以及隨機值server-id
??? innoDB_buffer_pool_size=內存*80%
??? server-id=[IP點分十進的后兩段]+三個隨機數
??? 公共用戶權限導入以及導入后驗證
?
?
該腳本的主要功能：
??? 從備份文件{logical，xtrabackup}恢復一個實例；
??? 從一個從庫直接{logical，xtrabackup}建立一個從庫；
??? 從一個主庫直接{logical，xtrabackup}建立一個從庫。
?
對于日常比較頻繁執行的DML語句，通常處于開發部門修改數據解決線上bug的問題，我們采用了inception的部分功能，結合已經收集到的服務器列表.，只需指定將SQL即可，平臺會自動送到該庫指向的主庫上執行DML語句。
?
采用inception的功能主要是對SQL的審核功能，例如，如果該SQL的影響行數超限，則終止執行。
?
平臺則對SQL執行進行歷史記錄。
?
?
DBA管理工具這邊也在逐步完成對上述管理腳本的平臺化。
?
我的分享基本就是這些， 關于平臺及工具的代碼，我們也在逐步做脫敏工作，爭取形成一個可以開源出來的產品， 希望對大家有些啟發，也希望拋磚引玉。
?
Q&A
?
Q1：目前的高可用是用什么方案？
A1：我們預期用MHA，目前還未有這方面的架構。
?
Q2：你們是如何進行跨機房的管理的？slave的延遲如何保證在業務可忍受的范圍內的？
A2：slave延遲的問題主要從開發方面分解大事務解決。跨機房方面我們目前也盡量避免跨機房的主從架構搭建。
?
Q3：如何設計MySQL架構來滿足如搶購類的高并發的業務？
A3：大促、秒殺業務這些方面，主要靠提前壓測，并觀察性能瓶頸，擴容和回收也是以性能（cpu，網絡連接，磁盤）為依據來進行。
?
Q4：目前應對大促，秒殺業務，數據庫層面擴容縮容，能否給出一些建議。
A4：這方面需要時間來改進，我們目前還很不完善，其實很多功能也是當當架構特色來設計的。即使開源也是為內部版本控制考慮。所以還未有這份精力配合。
?
Q5：如果要分庫分表，推進這些東西開發會配合嗎？
A5：我們架構部有這方面的中間價，叫sharding-JDBC，可以關注下github上的項目。
?
Q6：MySQL一個表最多存多少記錄算大數據？有哪些合適的分表方式？
A6：存多少不重要，關鍵要看怎么使用它，是讀多，寫多，還是改多，對于一般的系統，最起碼把讀寫分離開吧。
?
Q7：請問你們在線上如何解決DDL和批量delete or update 100萬級的數據的？
A7：DDL是靠pt-online-schema-change工具，百萬級的delete也是靠這個工具分配進行的。
轉載于:https://www.cnblogs.com/feiyun8616/p/6168830.html
總結
以上是生活随笔為你收集整理的转 当当网资深DBA：DB运维四大现代化的实现的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： xampp 下安装mysql-pytho
- 下一篇： 每个人都该懂点的版本管理技能