硬件相关的信息也是我们需要关注的，针对每种硬件我们都会有大致的QPS、TPS等指标，这个对于新上业务的评估以及评估现在数据库的瓶颈很有帮助，对于硬件你需要了结CPU核数、内存的大小、硬盘的介质（SAS？ PCIE SSD ？NVME SSD？），最好对线上的常见机型都有详细的压测数据。了解每一种机型在mysql中的表现，也是体现DBA专业度的一个指标。
经常有DBA由于不了解各个机型大致能支撑的性能 ，在方案选型和设备选型讨论中，无法肯定地确认具体需要什么设备，当前的设备配置是否能抗住对应的访问量，导致领导和开发对该DBA的专业度大打折扣。如果大家在日常工作中有空闲的机器，不妨使用sysbench、mysqlslap、fio等工具捣鼓一下。
3、运行状态作为DBA，我们还需要了解现在的实例的运行状态，如下几个指标都是我们需要了解的：
数据库数据量和表的数据量
#数据量到多少G，尤其是单表的数据量
实例负载情况（CPU负载、IO负载、系统负载）
慢查询情况
SQL延迟情况
锁情况
脏页情况
访问模型
#访问模型就是这数据库承担的是读多写少还是读少写多，以及是否是高并发等等
针对上述问题，可以采用pt-mysql-summary工具获取，再加以分析，也可以通过如下两个工具来实时查看
innotop
orzdba
<2>数据安全篇针对数据安全，主要包含如下几个部分
1、权限安全在权限方面，我们经常会看到有很多的数据库根本就没有密码，或者给业务的用户使用完全的权限（all privileges），或者是给某个帐号可以从任何地方登录的权限，这些都是非常致命的。建议在授予权限的时候注意如下几点：
数据库一定设置符合密码复杂度的用户密码
禁止给用户设置%的登录机器
只给业务最小权限的帐号，并限制登录的机器
2、数据一致性目前一般都是主从架构，主从的数据是否一致？90%以上的主从架构都缺乏数据一致性校验，之前遇到主从切换后数据不一致的情况，导致线上故障。
为了保证数据的一致性，记得周期性地使用pt-table-checksum来检查主从数据是否一致，如果不一致，可以使用pt-table-sync进行修复。
3、数据安全做为DBA，经常要思考，如果数据被误删，在现有的环境下是否会导致数据丢失。如果会，那就是你DBA工作没有做到位。主要考虑的指标为：
备份策略（数据库备份、binlog备份）
这里主要考虑3件事情：
3.1 数据备份策略是否合理
备份策略至少包含全量备份，和binlog增量备份，由于有从机，基本binlog都会比较安全
3.2 备份数据是否安全
备份数据是否安全，比如备份机器挂掉，是否所有的备份数据都会丢失，可以采用分布式文件系统或者在服务器中交错存放来规避。
3.3 备份数据是否可用
常常问自己，我们的备份数据都是有效的吗？周期性做备份数据还原的演练是必要的，确保备份数据的有效性。
<3>常规操作篇在操作数据库的时候，首先我们需要熟练常规的操作，常规的操作又分为两部分，一个是线上数据库的常规操作，一个是针对常见故障的预案的常规操作。熟练了操作和预案，才能在线上出问题的时候不至于手忙脚乱。
1、常规操作常规的操作一般包含如下几项
启动停止
数据库常规变更
索引优化
配置修改
数据库的备份
数据的迁移
切换
以上这些操作，包含的内容太多，DBA们可以自行google。总之要达到非常熟练的地步。如果命令记不住，建议将常规的操作通过关键字标记，并记录到类似印象笔记的文档中，要急用的时候可以快速搜索到。也可以写成工具脚本，随时调用。
2、常见故障的预案作为DBA，经常要面对各种突发的故障。大家要先搞清楚，不是遇到了故障我们才去找解决办法，而是在没有遇到故障之前就应该想到某一部分可能会出现问题，如果出现问题，我们应该当如何来应对。比如master出现故障，我们当如何处理？当你想到某个地方可能出现问题，那么就先将解决方案写出来。然后再找环境测试解决方案的可行性。验证了方案可行性之后，最好在线上安排对应的案例演习，确保解决方案可靠的。最终达到的效果是任何团队的任何一个成员对照文档都能处理类似的故障。
3、极端情况下的预案除了常见故障的预案，我们还应当思考极端情况下可能出现的故障（虽然可能永远都用不上），比如数据库主从都挂掉的情况。最好能拉上业务和开发的同学一起讨论，得出可行性的解决办法，然后找环境验证。当问题真的出现后，你会比没有预案的时候镇定很多，不至于一脸懵B。
4、定期演习预案做好以后最好能定期安排演习，开始搞互联网金融后有更深的体会，这边基本每个月都会有常规的演习。定期演习非常必要，通过演习，将演习过程中发现的问题都梳理出来，进行各个击破，确保各个预案都能正常工作。
<4>架构篇 1、你是一个合格DBA吗？作为运维DBA，肯定会接触到数据库的架构和业务架构，之前我们总监要求新入职的员工必须对你所要负责的数据库架构进行串讲，将不清楚的，不能直接上岗做线上操作。这个无疑是非常正确的，尤其是在腾讯这种公司，很多后端的逻辑都通过OSS进行封装，导致你能看到的只是web页面上的各个功能简单的按钮。只要轻轻一点，就能将很复杂的功能完成。这个对于后端逻辑没有好奇心的人是非常致命的。出了问题就找开发，导致自己的能力没有任何的提升，甚至还会在这种点鼠标的工作中日益退化。因此在架构篇部分其实想和大家聊的是在我们点鼠标的同时，还是要深入地去了解点鼠标背后发生的事情，知道异常如何分析和排查。甚至要再大胆一点，你也可以尝试着通过python或者go等语言去实现那些背后的逻辑，不要把自己局限在只是一个OP。因此我们在做运维的时候，不妨好好的问自己几个问题：
我点了鼠标之后，后端都干了什么事情？ 需要和哪些服务交互 ？
如果点完鼠标以后，报错了，需要如何进行排查？需要到哪里看日志？需要如何处理？
问完这两个问题，更次一点的是找研发详细了解里面的运行逻辑，以及部署详情，日志存放，出现问题如何排查等。更好的办法，是找研发要代码，然后自己去看对应按钮后面代码的逻辑。有的同学会说，我编码能力差，看不懂。这个不用担心，相信我，要基本看懂研发写的代码其实并没有那么难。践行一下你就会知道。等你看完研发的代码，估计很快就可以自己写一个类似的功能出来。
2、你真的了解线上的架构吗？
相关文章
精彩导读
热门资讯
关注我们
