MySQL 数据库巡检，DBA应该怎么做？_mysql 巡检

一套正常运行的系统是一个复杂的系统工程，牵涉到主机、操作系统、网络、数据库、中间件、底层存储，还有系统的核心：应用。任何层面的故障都可能造成系统的不可用。

今天聊一聊数据库层面的巡检问题。

数据库巡检的目的：保障数据库的正常运行，保证数据的安全性，完整性、可靠性。

这篇文章把我的这些个人的经验和想法总结下来，希望对大家有所帮助。

针对业务的不同，数据库巡检的侧重点也各不相同，但万变不离其宗，我认为核心思路集中在三点上：什么时候做巡检？怎么做巡检？巡检做到什么程度？

下面一一展开来说。

一、什么时候做巡检？

这块和公司业务类型密切相关，就我们而言，数据库巡检主要分为日常巡检和节前重点巡检。

日常巡检：其实也是DBA团队每天的日常工作之一，需要关注的数据库指标通过监控直接查看即可，有warning 或以上级别的告警还会发送告警邮件或者告警短信。绝大部分问题都可以由日常值班人员解决。

节前巡检：像国庆、春节、双十一等特殊日期，一般节前要做一次深度巡检，这是因为过节时由于人员放假，人员不足，需要提前巡检发现未来的问题，提前解决。

这里我总结了几个比较重要的巡检项：

• OS层面的CPU、Memory；
• 数据库集群高可用状态、复制状态、VIP状态；
• 空间使用率：文件系统、表空间不足的问题；
• 数据库运行趋势：数据库负载情况，近期是否存在高点或者持续增长的趋势；
• 参数：主机参数、数据库参数近期是否变动；
• 日志：系统日志、数据库日志里的报错信息；
• 用户安全：高权限的用户；
• 备份检查：节前做一次全备。

备注：如果数据库集群是MHA 架构，要通过巡检证明数据库是可切换状态。VIP 状态要定时探活， 复制状态是否正常等。

二、怎么做巡检？

常见的巡检方式包括手工巡检、脚本化巡检、平台化巡检。

不同的数据库规模对应不同的巡检方式，总体趋势都趋向脚本化、平台化。

如果管理的数据库服务器数量少（几台），巡检频率低的情况下（一周一次），可以采用手工巡检的方式。这种方式的缺点非常明显：不但效率底下还容易出错，同时也非常依赖巡检人员的技术水平。

稍微上点规模的数据库都必然采用脚本化巡检，所谓脚本化巡检其实就是把巡检的命令打包做成一个脚本，可以是Shell或者是Python脚本。只需要在某台服务器执行脚本，所有的数据库都会巡检到。脚本生成html 报表或者其他格式的数据，供DBA团队分析和汇总。

脚本化巡检可以轻松实现在数百上千个实例上做巡检并完成巡检报告。当然，因为脚本需要编写和维护，需要DBA有Shell或者Python语言编写能力。

更进一步的是平台化巡检，可能要依赖第三方平台。其实平台化也不过是封装了巡检命令，只是用起来更加智能化、标准化。

三、巡检做到什么程度？

巡检需要做什么程度？在于我们是想解决什么问题。

如果想让数据库不但可用，并且可靠和跑得更快。那么我认为巡检要做到这种程度：可用性巡检 + 可靠性巡检 + 性能巡检 + 分析和建议。

可用性巡检 

其实日常巡检已经大量检查了数据库的可用性，但那些都是从运维角度、从服务、从实例级别来衡量的。从应用角度、从业务角度有没有能做的巡检项呢？也是有的。

我们在生产中就遇到过这样的情况，某业务有一张日志表，每天入表的记录数一般为 1000 万条，当时这张表采用的是intunsigned 自增 id 作为主键，在业务上线不到 5 个月自增主键就用完了。解决办法就是修改自增利类型，从 int unsigned 修改为 bigint signed，我们知道 MySQL 修改主键列类型是锁表的，只能读不能写，所以当时这个业务受损了，DDL 花了 6 个小时。

所以从应用角度、从业务角度需要对这些情况，做可用性巡检的扩展。

可靠性巡检

可靠性不等于可用性，这里不要混淆。

可用性指的是Availability，一般是高可用要解决的问题，而可靠性指的是 Reliability，在数据库里一般指的是数据不错、不丢和数据副本的一致性。

举个例子，我们目前做可靠性巡检会检查数据库运行参数和配置文件(my.cnf)参数是否一致，为什么这么做呢？

很多人以为持久化的配置文件一定会和运行参数一致，这不一定。

在 MySQL 5.7 或之前，没有办法修改参数同时持久化配置文件，所以修改参数通常都是分两步，先在数据库里 set global 参数=值，然后登陆服务器修改my.cnf 配置文件，因不是原子操作，那么运维人员就有犯错的可能，人总是会犯错的。

之前我们就发生过好几次运行参数和持久化配置文件不一致产生的故障。例如，动态修改MySQL 的innodb_buffer_pool_size = 128G，然后忘记持久化到配置文件了。当时数据库发生了crash，之后被高可用组件拉回 mysqld 实例，发现性能很差，这个排查了半天，居然是 innodb_buffer_pool_size 被还原了默认值 128M !

另外，某些租户是持有 super 权限，可以修改数据库的参数，但他们是没有服务器权限，如果这些租户修改的参数涉及了我们认为的核心参数，造成这个核心参数的运行参数和配置文件(my.cnf)参数不一致，那就有可能埋了雷，后续引发数据库可靠性甚至是可用性问题了。

性能巡检 

性能巡检上，我这里介绍一些常见的。

1、是否存在没有主键的表。最好是业务无关的 int signed 自增主键。

2、 top 10 慢查询、top10 全表扫描等，优化 SQL。

3、索引方面，可以关注冗余索引、无效索引、索引区分度等信息。冗余索引意思是数据库里有重复的索引，无效索引，就是从未使用过的索引。索引区分度用于评估列的值是否足够分散，值越多越适合建立索引。

4、TOP 10 大表 大表在做全表扫描时非常耗费性能，在 DDL 方面的话更是灾难，大于 100G 的表都应该评估一下，为什么会有那么大的表？为什么会放在 MySQL 上，是否可以放到其他数据库上？是否可以拆分为小表，是否可以归档？

建议：MySQL 单实例的存储空间大小应控制在 500G，单表行数控制在 1000 万行以内、大小在30G以内，单表字段 50 个以内，单表索引 5 个以内。

以上就是我个人对 MySQL 数据库巡检需要做什么的一些想法，欢迎指正。