MySQL数据库运维的五大指标(1)

如何评价一个公司数据库运维水平的高低？用什么来进行横向与纵向对比？自动化平台建设的目标是什么？必须有相应的指标体系来指导，此指标体系必须满足以下条件：

• 可以用数字来测算和衡量
• 最终指标，而不是中间指标

比如有时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个指标都量化记录下来，并采用各种方法持继改进指标，相信最终会建立一个比较好的运维平台。