MySQL数据库运维的五大指标

如何评价一个公司数据库运维水平的高低？用什么来进行横向与纵向对比？自动化平台建设的目标是什么？必须有相应的指标体系来指导，此指标体系必须知足如下条件： 
• 能够用数字来测算和衡量 
• 最终指标，而不是中间指标 
好比有时DBA会关注数据库的吞吐量，但吞吐量越高不能表明数据库提供的服务质量越好，开发人员关心这个指标的缘由也是由于担忧太高的吞吐量会影响响应时间或者形成系统不可用，因此这只是一个中间指标。 
• 能够全面衡量一个网站的数据库运维水平，而不会顾此失彼 
• 有人文关注

1.1. 数据安全 
数据安全是第一位的，DBA的首要职责必须保证不丢数据，丢掉数据就丢掉了饭碗！ 
这有3方面的含义： 
1）在人为误操做的时候（update,insert,delete,drop,alter)，可以恢复数据到正确的状态
2）在机房，硬件故障或者操做系统，数据库软件故障的时候，可以恢复数据到正确的状态 
3）不丢事务，保证已经入库的数据可以被正确的查询到 
另外，还要注意到须要保证主从数据库的一致性，不然读写分离的状况下其实在用户看来仍然丢失了数据。 
对于1，主要靠备份来保证，由于复制能够容灾，却不能够容错（固然延迟备份在必定程度能够）。 
对于2，可能用备份来恢复，也可能直接进行主库或者从库的切换来恢复服务 
对于3，电商，支付库的要求会很是高，采用最高安全级别的数据库软硬件设置以及冗余设备，目标是不丢任何1个事务，由于即便1个事务也可能形成大量金钱的损失，同时形成企业信誉的降低。 
“911”事件曾形成1200家公司受灾，其中一半以上的企业由于IT数据损毁、丢失，致使业务没法恢复，以至于宣布倒闭。金融界巨头Morgan Stanley 全球营业部次日就恢复正常工做，正是由于先前创建的远程容灾系统保护了重要的数据。 
可测量指标： 
RPO（Recovery Point Object）：恢复点指标，是指灾难发生后，容灾系统能把数据恢复到灾难发生前的哪个时间点的数据，它衡量企业在灾难发生后会丢失多少生产数据 
RTO（Recovery Time Object）：系统恢复的时间 
RPO说明了备份的可靠性和完整性，RTO说明了恢复的可靠性与速度。 
因为MySQL开源版本并不提供热备的工具以及备份管理的工具（ＭSSQL，Oracle是提供的，固然它们是商业软件），因此要求ＤBA开发出本身的备份还原管理平台（脚本）。这也是DBA的首件工做。

1.2. 无端障（停机）时间 
运维和开发不同，开发最重要的是保证必定效率的状况下实现功能，同时程序Bug少。运维讲的是提供稳定服务的时间。用术语来讲就是几个9，具体含义就是年度不可服务（不论是主动的仍是被动的）时间除以整年时间，百分比越高越好。具体和时间的换算关系见下表： 

根据墨菲定理（If anything can go wrong,it will）的推论，世界上没有 100% 可靠的 Web站点(除非不运行)。运维的最高境界固然就是5个9了，一年停机时间只有5分钟，这是至关难以达到的目标，每每一个大故障就会把整年的停机时间用完。 
业界网站的可用性都是多少？引人注目的 Web 新贵 Twitter (http://twitter.com)， 2008 年前四个月的可用性只有 98.72%，有 37小时 16分钟不能提供服务，连2个9 都达不到，甚至还没达到”基本可用”状态。电子商务巨头 eBay 2007 年的可用性是 99.94%，考虑到 eBay 站点的规模与应用的复杂程度，这是个很不错可用性指标了。 
多数状况下，网站可用性会是 SLA （Service Level Agreement, 服务水平协议) 中的一个重要度量指标，也是运维团队向本身老板作出的正式承诺。但可用性是可以持续改进的东西，运维负责人不可但愿一步登天。 
另外，若是是作第三方托管，须要明确第三方的服务能力与责任。不然，IDC 常常断电或者断网，即便自身作的再好也没法保证服务时间了。 
提升可用性的一些常规策略有消除单点，部署冗余设备等。若是要提供更高的可用性，好比 4 个 9 甚至 5 个9，就不是简单靠硬件就能作到的事情，还须要创建自动化的工具与平台，完善的流程制度与变动机制，7*24小时的专人值班等。 
可测量指标： 
年度不可服务时间比例：年度不可服务（不论是主动的仍是被动的）时间除以整年时间。

1.3. 响应时间 
响应时间是指一条查询或者更新语句从发出请求到接收完数据的时间。 
由于最大响应时间的不肯定性和不可重复性，因此通常使用X%的查询响应时间做为指标。若是值为95%为10ms，意味着95%的查询会在10ms内返回。对于OLTP查询来讲，在50ms内返回是比较理想的结果。超过200ms的查询能够视为慢查询。 
此指标较难收集，采用tcprstat虽然能够，可是tcprstat自己有必定的负载，另外也只收集最高到99%的响应时间，若是想知道好比99.999%的平均、最大响应时间就须要修改源码了。 
目前有2个思路收集此数据： 
采用tcpdump+pt-query-digest，将tcpdump抽样数据发送到中心机上利用pt-query-digest进行分析，而后入库后显示。此方法也须要修改pt源码，由于原版的pt支持的粒度太粗了，以下图，100ms直接跳到了1s：

此方法的优势是能够显示不一样语句的状况，缺点是若是抽样时间长，中心机分析不完，而抽样时间短又可能信息没有表明性。 
另一个更轻量级的方法是将慢查询日志阀值打到50ms甚至更低，而后统计慢查询时间的分布，能够按时间和服务器维度进行分析（使用pt工具也能够获得不一样语句的响应时间分布）以下表所示： 
4901 130421 
dt num avg 
—————————– 
0 1839 605 
1 920 596 
2 1215 450 
3 973 481 
4 488 603 
5 449 487 
6 516 597 
7 874 634 
8 1129 532 
9 1160 457 
10 1115 502 
11 987 529 
12 1531 559 
13 1185 537 
14 2238 1235 
15 1418 534 
16 1589 535 
17 951 548 
18 1790 531 
19 1520 503 
20 1845 496 
21 1855 542 
22 1583 564 
23 1840 562 
None 31010 587

ip num ratio 
—————————– 
10.73.xx.xx 4418 14 
10.75.xx.xx 121 0 
10.75.xx.xx 7905 25 
10.75.xx.xx 5706 18 
10.75.xx.xx 6812 22 
10.75.xx.xx 6048 20 
None 31010 100 
根据此结果能够发现慢查询在服务器之间分布并不均衡，这也是分析问题的很好的切入点。

可测量指标： 
X%的查询/写入响应时间（ms）。

1.4. 成本 
在解决了稳定和速度后，就是成本的问题了。有人认为若是不计较成本，任何功能都是能够实现的，而且不须要高深的技术。我不彻底认同这个观点。但架构师的使命的确不只仅是“完成”功能，若是说完成功能能够有50种方法， 
由于经济学上认为找到最优方案可能成本比回报还要高，那么至少要找出相对较优的几种方法并进行最终的选择。 
成本的构成主要是硬件成本＋软件成本＋人力成本，由于互联网企业软件以自主开发和开源为主，因此其中主要是硬件和人力成本，硬件成本也包含了机房的机架，带宽，电力成本。 
对大型互联网公司来讲，服务器规模都在上万台以上，Google的服务器规模更达到了百万级。而互联网公司的人才规模也是至关惊人，TAB公司的人员都在万人以上。 
所以如何可以提升硬件的使用效率，下降人工运维成本，提升人均产出，也就成为关系到互联网公司生死存亡的事情了。 
可测量指标： 
投入成本＝硬件成本（含机架，带宽，电力）＋软件成本(ＭySQL可忽略) ＋人力成本

1.5. 运维人员幸福度 
运维自动化是方向不假，但目前阶段来讲，有不少工做还须要人来完成，越是复杂的工做越须要人工干预。对于一些创业公司，自动化平台更是要从头打造，此时间段内的不少操做须要手工完成。 
克拉克的《与拉玛相会》描绘了一个彻底靠机器人运维，在太空中飞行了上万年的巨大人工飞行器。但如今科技毕竟离此阶段还差得远。人也不是机器人，是有个性，独一无二的智慧生物。

为了体现运维的人文关怀，必须加入人员幸福度指标。 
幸福度能够从3方面考量： 
1）人均承担数据库读写量（若是数据库读写量大，这个值低，那么必然运维人员多，人均产值/薪酬低） 
2）运维人员长期从事机械化的，重复性工做的时间比例 
3）运维人员在工做时间之外进行切换上线，故障处理的时间比例 
若是这3项指标差， 那就意味着团队的幸福感差，必然离职率高。因此离职率也是衡量指标之一。

若是有一个系统可以将上面的5个指标都量化记录下来，并采用各类方法持继改进指标，相信最终会创建一个比较好的运维平台。

 

 

原文  http://www.iamcjd.com/?p=1285