MySQL数据库运维的五⼤指标
如何评价⼀个公司数据库运维⽔平的⾼低？⽤什么来进⾏横向与纵向对⽐？⾃动化平台建设的⽬标是什么？必须有相应的指标体系来指导，此指标体系必须满⾜以下条件：
• 可以⽤数字来测算和衡量
• 最终指标，⽽不是中间指标
⽐如有时DBA会关注数据库的吞吐量，但吞吐量越⾼不能代表数据库提供的服务质量越好，开发⼈员关⼼这个指标的原因也是因为担⼼过⾼的吞吐量会影响响应时间或者造成系统不可⽤，所以这只是⼀个中间指标。
• 可以全⾯衡量⼀个⽹站的数据库运维⽔平，⽽不会顾此失彼
• 有⼈⽂关注
1.1. 数据安全
数据安全是第⼀位的，DBA的⾸要职责必须保证不丢数据，丢掉数据就丢掉了饭碗！
这有3⽅⾯的含义：
1）在⼈为误操作的时候（update,insert,delete,drop,alter)，能够恢复数据到正确的状态
2）在机房，硬件故障或者操作系统，数据库软件故障的时候，能够恢复数据到正确的状态
3）不丢事务，保证已经⼊库的数据能够被正确的查询到
另外，还要注意到需要保证主从数据库的⼀致性，否则读写分离的情况下其实在⽤户看来仍然丢失了数据。
对于1，主要靠备份来保证，因为复制可以容灾，却不可以容错（当然延迟备份在⼀定程度可以）。
对于2，可能⽤备份来恢复，也可能直接进⾏主库或者从库的切换来恢复服务
对于3，电商，⽀付库的要求会⾮常⾼，采⽤最⾼安全级别的数据库软硬件设置以及冗余设备，⽬标是不丢任何1个事务，因为即使1个事务也可能造成⼤量⾦钱的损失，同时造成企业信誉的下降。
“911”事件曾造成1200家公司受灾，其中⼀半以上的企业因为IT数据损毁、丢失，导致业务⽆法恢复，以致于宣布倒闭。⾦融界巨头Morgan Stanley 全球营业部第⼆天就恢复正常⼯作，正是因为先前建⽴的远程容灾系统保护了重要的数据。
php进行文件下载可测量指标：
RPO（Recovery Point Object）：恢复点指标，是指灾难发⽣后，容灾系统能把数据恢复到灾难发⽣前的哪⼀个时间点的数据，它衡量企业在灾难发⽣后会丢失多少⽣产数据
RTO（Recovery Time Object）：系统恢复的时间
RPO说明了备份的可靠性和完整性，RTO说明了恢复的可靠性与速度。
由于MySQL开源版本并不提供热备的⼯具以及备份管理的⼯具（ＭSSQL，Oracle是提供的，当然它们是商业软件），所以要求ＤBA开发出⾃⼰的备份还原管理平台（脚本）。这也是DBA的⾸件⼯作。
1.2. ⽆故障（停机）时间
运维和开发不⼀样，开发最重要的是保证⼀定效率的情况下实现功能，同时程序Bug少。运维讲的是提供稳定服务的时间。⽤术语来说就是⼏个9，具体含义就是年度不可服务（不管是主动的还是被动的）时间除以全年时间，百分⽐越⾼越好。具体和时间的换算关系见下表：
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
eclipse开发环境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
html竖滚动条None 31010 587
ip num ratio
—————————–
4418 14
121 0
7905 25
5706 18
6812 22
fwrite写文件是空的
6048 20
None 31010 100
根据此结果可以发现慢查询在服务器之间分布并不均衡，这也是分析问题的很好的切⼊点。
ztreeapi可测量指标：
X%的查询/写⼊响应时间（ms）。
1.4. 成本
在解决了稳定和速度后，就是成本的问题了。有⼈认为如果不计较成本，任何功能都是可以实现的，并且不需要⾼深的技术。我不完全认同这个观点。但架构师的使命的确不仅仅是“完成”功能，如果说完成功能可以有50种⽅法，
因为经济学上认为到最优⽅案可能成本⽐回报还要⾼，那么⾄少要出相对较优的⼏种⽅法并进⾏最终的选择。
成本的构成主要是硬件成本＋软件成本＋⼈⼒成本，因为互联⽹企业软件以⾃主开发和开源为主，所以其中主要是硬件和⼈⼒成本，硬件成本也包含了机房的机架，带宽，电⼒成本。
对⼤型互联⽹公司来说，服务器规模都在上万台以上，Google的服务器规模更达到了百万级。⽽互联⽹公司的⼈才规模也是相当惊⼈，TAB 公司的⼈员都在万⼈以上。
因此如何能够提⾼硬件的使⽤效率，降低⼈⼯运维成本，提⾼⼈均产出，也就成为关系到互联⽹公司⽣死存亡的事情了。
可测量指标：
mysql是什么系统投⼊成本＝硬件成本（含机架，带宽，电⼒）＋软件成本(ＭySQL可忽略) ＋⼈⼒成本
1.5. 运维⼈员幸福度
运维⾃动化是⽅向不假，但⽬前阶段来说，有很多⼯作还需要⼈来完成，越是复杂的⼯作越需要⼈⼯⼲预。对于⼀些创业公司，⾃动化平台更是要从头打造，此时间段内的很多操作需要⼿⼯完成。
克拉克的《与拉玛相会》描绘了⼀个完全靠机器⼈运维，在太空中飞⾏了上万年的巨⼤⼈⼯飞⾏器。但现在科技毕竟离此阶段还差得远。⼈也不是机器⼈，是有个性，独⼀⽆⼆的智慧⽣物。
为了体现运维的⼈⽂关怀，必须加⼊⼈员幸福度指标。
幸福度可以从3⽅⾯考量：
1）⼈均承担数据库读写量（如果数据库读写量⼤，这个值低，那么必然运维⼈员多，⼈均产值/薪酬低）
2）运维⼈员长期从事机械化的，重复性⼯作的时间⽐例
3）运维⼈员在⼯作时间以外进⾏切换上线，故障处理的时间⽐例
如果这3项指标差，那就意味着团队的幸福感差，必然离职率⾼。所以离职率也是衡量指标之⼀。
如果有⼀个系统能够将上⾯的5个指标都量化记录下来，并采⽤各种⽅法持继改进指标，相信最终会建⽴⼀个⽐较好的运维平台。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。