阮胜昌的技术记录站-LinuxMySQL数据库运维

专职做 DBA 已经 6 年多的时间了，一路走来，感触非常深。看同行、同事犯了太多的错误，同样我自己也犯了非常多的错误，然而绝大多数的错误其实都是很低级的错误。

有的是因为不了解某个引擎的特性导致、有的是因为对线上环境不了解导致、有的是因为经验不足导致。一路上，跌跌撞撞，从小公司 DBA，到腾讯高级 DBA，再到现在的金融数据库 DBA。

不由得想起 5 年前的我，刚进入 DBA 行业，缺乏经验，经常犯错误，不是我不够努力，更多的是初来乍到的我根本不知道应该在哪方面下功夫。

本文就是基于这方面的考虑，根据自己在 DBA 这个职业上走过的弯路，总结一些方法给 DBA 的同行。希望本文能给同行 DBA 或者运维的朋友们带来一些改变，让大家知道作为一个 DBA 需要在哪些方面下功夫。

下面主要从环境、数据安全、常规操作、预案、架构、心态等层面进行分享，同时也会介绍一些实用的经验。

环境篇

毫无疑问，DBA 是需要综合技能最多的一个职业，需要你有网络、操作系统、文件系统、数据库、安全、编程等知识。

作为 DBA，为了少犯错误，你首先得非常熟悉你负责的数据库环境，大到网络环境、系统环境、数据库环境(这里主要以MySQL为例)。如果不熟悉环境，很容易因为自身操作考虑不周而导致线上的故障。

想想就知道，有多少 DBA 因为 alter 操作导致的线上故障?有多少 DBA 忽略了字符集的问题导致了线上的乱码?又有多少 DBA 由于迁移的时候没有备份触发器或者 event 导致的故障?太多的教训足以让我们所有的 DBA 认识到熟悉环境的重要性。

另外 DBA 对线上环境如果足够了解，在处理故障、讨论处理方案等，都能极大地增强我们的自信，更好地提升自己的影响力。

我们可以说不熟悉环境的 DBA 不是好 DBA。下面来介绍环境部分 DBA 应该注意的问题：

软件环境

操作系统环境

针对操作系统部分，你可能需要了解的是使用的操作系统类型，Linux or Windows，该系统做了哪些内核的优化，尤其是针对数据库。

比如文件描述符、配置 ntp、raid 的写 cache 模式等，另外你还要对系统的运行状态有大致的了解，CPU 使用、内存使用、IO 使用以及网络带宽和包量的情况。

数据库环境

数据库环境包含的内容就非常多了，这里只介绍如果不了解比较容易造成误操作的部分：

部署方式

对于数据库的部署，我们需要了解数据库是如何部署的，部署在了什么目录，可执行文件、数据文件、log 文件、配置文件等的存放路径，数据库如何启动和停止等。

使用引擎

了解目前数据库默认使用的引擎，以及现有的表使用的引擎，提前清楚地了解各个引擎的特点和使用，避免在出现数据迁移、表损坏以及启动问题手忙脚乱导致误操作。

我们的技术就像武器库，都是靠平时闲淡中的积累和打造，在出问题的时候直接从武器库拿来使用，因此要经常丰富我们的“武器库”。

备注：虽然现在基本使用的都是 innodb 引擎，但是，你也同样可以发现有的还用了 Myisam，甚至还有的用到了 memory、merge、spider、tokuDB 等。

同步方式

目前 MySQL 基本都会配置同步(如果没有一定要加上，除非是数据丢了或者长时间故障也没关系的库)，既然涉及到同步就会有多种不同的方式。

比如常见的分类：

• 基于 binlog 和 pos 的同步。
• 基于 GTID 的同步。
• 异步。
• 半同步。
• 单线程同步。
• 多线程同步。

针对这些同步，都有一些不同的特点，比如出现问题了，需要跳过某个位置，gtid 的同步和基于 pos 的同步操作就不一样，同步方式也是你必须掌握的技巧。

版本

在维护数据库的时候，还需要了解当前数据库使用的大版本。因为数据库的大版本的功能会有很大的差异，有很多特性是只存在某个大版本的。

因此了解使用的版本能让你大致知道当前数据库支持哪些特性。在涉及到迁移、同步、数据库升级等操作的时候，能从容应对。

存储过程(procedure)、事件(event)

了解当前数据库是否存在存储过程和事件，在数据备份、数据迁移的时候，需要将对应的存储过程和事件的参数添加进去。

另外如果存在事件，在迁移的时候会有特殊的操作，在迁移的目标机器要先将事件关闭，切换后再打开。防止事件导致数据不一致。

关键配置

MySQL 有几项非常关键的配置，需要了解清楚，避免由于配置没搞清楚导致误操作，总结关键配置如下：

innodb_buffer_pool_size 
 
#对innodb生效，对性能影响非常大，一般可以设置内存的50~80% 
 
key_buffer_size 
 
#对Myisam生效，建议修改成innodb 
 
innodb_flush_log_at_trx_commit 
 
#innodb的redo日志刷新方式，对innodb的影响会很大，一般设置为2log 
 
-bin 
 
#是否开始binlog，如果没有开启，一定要开启 
 
sync_binlog 
 
#刷binlog的方式，一般设置为0，如果对数据需要强一致的，可以将sync_binlog设置为大于1的数，兼顾安全和性能 
 
innodb_file_per_table 
 
#采用独立表空间，建议都设置成独立表空间，不然后面磁盘空间满了，删除表空间也无法释放，必须做数据迁移 
 
lower_case_table_names 
 
#表明区分大小写 
 
character_set_server 
 
#字符集在迁移、数据库变更、数据导入等都是必须要注意的，不然数据乱码了就会很麻烦 
 
max_connections 
 
#最大连接数不能设置太大，要计算一下session内存*max_connections + 固定内存 < 总内存-2G(这2G用来做系统内存，留给系统的内存可以再设大一点) 
 
transaction_isolation 
 
#设置隔离级别，默认是Repeatable Read，如果是binlog是row模式，也经常设置为Read Committed级别 

所有上面说的参数，都需要深入了解和熟悉，当我们在做数据迁移的时候或者搭建MySQL 的时候，一定要比对一下源实例的配置(比对工具可以参考 pt-config-diff 工具)，以免迁移完成后由于参数不一致，中途要重启实例的情况。

在这个问题上，我见过太多的教训，希望大家能吸取教训，减少故障和问题的发生。

数据库环境收集工具介绍

前面我们介绍了数据库相关的环境，对于那么多的环境变量，我们如何更好的去收集，这里给大家介绍一个工具。

pt-mysql-summary

这个工具的具体用法可以 Google 了解，也可以访问如下链接了解，不在本文的论述范围：https://www.percona.com/doc/percona-toolkit/2.1/pt-mysql-summary.html

硬件

硬件相关的信息也是我们需要关注的，针对每种硬件我们都会有大致的 QPS、TPS 等指标，这个对于新上业务的评估以及评估现在数据库的瓶颈很有帮助。

对于硬件你需要了结 CPU 核数、内存的大小、硬盘的介质(SAS? PCIE SSD ?NVME SSD?)，最好对线上的常见机型都有详细的压测数据。

了解每一种机型在 MySQL 中的表现，也是体现 DBA 专业度的一个指标。

经常有 DBA 由于不了解各个机型大致能支撑的性能 ，在方案选型和设备选型讨论中，无法肯定地确认具体需要什么设备，当前的设备配置是否能抗住对应的访问量，导致领导和开发对该 DBA 的专业度大打折扣。

如果大家在日常工作中有空闲的机器，不妨使用 sysbench、mysqlslap、fio 等工具捣鼓一下。

运行状态

作为 DBA，我们还需要了解现在的实例的运行状态，如下几个指标都是我们需要了解的。

数据库数据量和表的数据量，数据量到多少 G，尤其是单表的数据量：

• 实例负载情况(CPU负载、IO负载、系统负载)
• 慢查询情况
• SQL延迟情况
• 锁情况
• 脏页情况
• 访问模型

访问模型就是这数据库承担的是读多写少还是读少写多，以及是否是高并发等等。

针对上述问题，可以采用 pt-mysql-summary 工具获取，再加以分析，也可以通过如下两个工具来实时查看：

• innotop
• orzdba

数据安全篇

针对数据安全，主要包含如下几个部分：

权限安全

在权限方面，我们经常会看到有很多的数据库根本就没有密码，或者给业务的用户使用完全的权限(all privileges)，或者是给某个帐号可以从任何地方登录的权限，这些都是非常致命的。

建议在授予权限的时候注意如下几点：

• 数据库一定设置符合密码复杂度的用户密码。
• 禁止给用户设置 % 的登录机器。
• 只给业务最小权限的帐号，并限制登录的机器。

数据一致性

目前一般都是主从架构，主从的数据是否一致?90% 以上的主从架构都缺乏数据一致性校验，之前遇到主从切换后数据不一致的情况，导致线上故障。

为了保证数据的一致性，记得周期性地使用 pt-table-checksum 来检查主从数据是否一致，如果不一致，可以使用 pt-table-sync 进行修复。

数据安全

做为 DBA，经常要思考，如果数据被误删，在现有的环境下是否会导致数据丢失。如果会，那就是你 DBA 工作没有做到位。

主要考虑的指标为：

• 备份策略(数据库备份、binlog 备份)。

这里主要考虑三件事情：

• 数据备份策略是否合理。备份策略至少包含全量备份和 binlog 增量备份，由于有从机，基本 binlog 都会比较安全。
• 备份数据是否安全。备份数据是否安全，比如备份机器挂掉，是否所有的备份数据都会丢失，可以采用分布式文件系统或者在服务器中交错存放来规避。
• 备份数据是否可用。常常问自己，我们的备份数据都是有效的吗?周期性做备份数据还原的演练是必要的，确保备份数据的有效性。