专职做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的同步操作就不一样，同步方式也是你必须掌握的技巧。

在维护数据库时，还需要了解当前数据库使用的大版本。因为数据库的大版本的功能会有很大的差异，有很多特性是只存在某个大版本的，因此了解使用的版本能让你大致知道当前数据库支持哪些特性。在涉及到迁移、同步、数据库升级等操作的时候，能从容应对。

了解当前数据库是否存在存储过程和事件。在数据备份、数据迁移的时候，需要将对应的存储过程和事件的参数添加进去。另外如果存在事件，在迁移的时候会有特殊的操作，在迁移的目标机器要先将事件关闭，切换后再打开。防止事件导致数据不一致。

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

• innodb_buffer_pool_size

#对innodb生效，对性能影响非常大，一般可以设置内存的50~80%

• key_buffer_size

#对Myisam生效，建议修改成innodb

• innodb_flush_log_at_trx_commit

#innodb的redo日志刷新方式，对innodb的影响会很大，一般设置为2

• log-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），或者是给某个帐号可以从任何地方登录的权限，这些都是非常致命的。建议在授予权限的时候注意如下几点：

1. 数据库一定设置符合密码复杂度的用户密码；

2. 禁止给用户设置%的登录机器；

3. 只给业务最小权限的帐号，并限制登录的机器。

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

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

作为DBA，经常要思考，如果数据被误删，在现有的环境下是否会导致数据丢失。如果会，那就是你DBA工作没有做到位。主要考虑的指标为：备份策略（数据库备份、binlog备份）。这里主要考虑3件事情：

备份策略至少包含全量备份，和binlog增量备份，由于有从机，基本binlog都会比较安全。

备份数据是否安全。比如备份机器挂掉，是否所有的备份数据都会丢失。我们可以采用分布式文件系统或者在服务器中交错存放来规避。

常常问自己，我们的备份数据都是有效的吗？周期性做备份数据还原的演练是必要的，确保备份数据的有效性。

在操作数据库的时候，首先我们需要熟练常规的操作。常规的操作又分为两部分，一个是线上数据库的常规操作，另一个是针对常见故障的预案的常规操作。熟练了操作和预案，才能在线上出问题的时候不至于手忙脚乱。

常规的操作一般包含如下几项：

• 启动停止

• 数据库常规变更

• 索引优化

• 配置修改

• 数据库的备份

• 数据的迁移

• 切换

以上这些操作，包含的内容太多，DBA们可以自行Google。总之要达到非常熟练的地步。如果命令记不住，建议将常规的操作通过关键字标记，并记录到类似印象笔记的文档中，要急用的时候也可以快速搜索到。也可以写成工具脚本，随时调用。

作为DBA，经常要面对各种突发的故障。大家要先搞清楚，不是遇到了故障我们才去找解决办法，而是在没有遇到故障之前就应该想到某一部分可能会出现问题，如果出现问题，我们应当如何来应对。比如Master出现故障，我们当如何处理？当你想到某个地方可能出现问题，那么就先将解决方案写出来。然后再找环境测试解决方案的可行性。验证了方案可行性之后，最好在线上安排对应的案例演习，确保解决方案可靠的。最终达到的效果是任何团队的任何一个成员对照文档都能处理类似的故障。

除了常见故障的预案，我们还应当思考极端情况下可能出现的故障（虽然可能永远都用不上），比如数据库主从都挂掉的情况。最好能拉上业务和开发的同学一起讨论，得出可行性的解决办法，然后找环境验证。当问题真的出现后，你会比没有预案的时候镇定很多，不至于一脸懵B。

预案做好以后最好能定期安排演习，开始搞互联网金融后有更深的体会了，这边基本每个月都会有常规的演习。定期演习非常必要，通过演习，将演习过程中发现的问题都梳理出来，进行各个击破，确保各个预案都能正常工作。

作为运维DBA，肯定会接触到数据库的架构和业务架构。之前我们总监要求新入职的员工必须对你所要负责的数据库架构进行串讲，讲不清楚的，不能直接上岗做线上操作。这个无疑是非常正确的，尤其是在腾讯这种公司，很多后端的逻辑都通过OSS进行封装，导致你能看到的只是Web页面上的各个功能简单的按钮。只要轻轻一点，就能将很复杂的功能完成。这个对于后端逻辑没有好奇心的人是非常致命的。出了问题就找开发，导致自己的能力没有任何的提升，甚至还会在这种点鼠标的工作中日益退化。

因此在架构篇部分其实想和大家聊的是在我们点鼠标的同时，还是要深入地去了解点鼠标背后发生的事情，知道异常如何分析和排查。甚至要再大胆一点，你也可以尝试着通过Python或者Go等语言去实现那些背后的逻辑，不要只是把自己局限在做一个OP。因此我们在做运维的时候，不妨好好地问自己几个问题：

我点了鼠标之后，后端都干了什么事情？ 需要和哪些服务交互 ？如果点完鼠标以后，报错了，需要如何进行排查？需要到哪里看日志？需要如何处理？

问完这两个问题，更次一点的是找研发详细了解里面的运行逻辑，以及部署详情，日志存放，出现问题如何排查等。更好的办法，是找研发要代码，然后自己去看对应按钮后面代码的逻辑。

有的同学会说，我编码能力差，看不懂。这个不用担心，相信我，要基本看懂研发写的代码其实并没有那么难。践行一下你就会知道。等你看完研发的代码，估计很快就可以自己写一个类似的功能出来。

现在数据库高可用架构比较多，不管是单纯地使用主从架构、MHA、MMM、NBD Cluster或是集成了LVS、Keepalived等组件，我们都不应该仅仅停留在正常情况下会搭建、操作和使用对应的架构。更多的是，我们需要更深入地去了解里面运作的机理。就以MHA为例，它是如何检测某一个实例异常的？各个组件之间如何配合？当做切换的时候，MHA是如何保证数据的一致性？如果后端有多台Slave，它是如何选择哪一台从机做切换，并且，其他从机如何处理？

只有深入了解了逻辑之后，在遇到故障和问题，你就能更快速地进行定位，减少对业务的影响。此外你还能有针对性的做自动化，让自己工作更轻松。这么好的事情，为什么不践行一下？

还有一个问题，就是作为DBA要尽可能地去了解业务，了解业务的读写模型，了解业务相关架构，了解业务如何使用数据库。这样做的好处是你能针对业务的场景给出更好的优化建议，出了问题也能快速判断对业务的影响情况。

DBA面对线上复杂的环境，尤其是面对高并发的环境，很容易导致线上故障，下面是整理的一些容易导致线上故障的操作以及规避误操作的技巧，希望能对各位DBA有所帮助：

1. 修改或删除数据前先备份，先备份，先备份（重要事情说三遍） ；

2. 线上变更一定要有回退方案；

3. 批量操作中间添加sleep；

4. DDL操作要谨慎，对于大表的Alter操作最好使用pt-online-schema-change；

5. 变更操作先在测试环境测试；

6. 重启数据库前先刷脏页；

7. 禁止批量删除大量的binlog；

8. 对于变更操作一定要写详细的操作步骤，并review；

9. 按enter之前再进行一次环境确认；

10. 如果你的操作可能会使状况变得更糟，请停止操作；

11. 快速处理磁盘满，使用tune2fs释放文件系统保留块；

12. 连接数满先修改内存变量，而不是重启，修改方式如下：

    gdb -p pid -ex "set max_connections=1000" -batch 

    #pid是mysqld的对应的pid。

从某种意义上讲，DBA是一个高危的行业，不是开玩笑，看看下面的截图就知道：

风险本身是个伪命题，对于某些人来说是风险，但对于某些人来说其实没有风险。就像医生做手术一样，我们常人看来就是个非常危险的事情，但是对于医生来讲，其实并没有什么风险（大部分的手术）。因此风险在于你是否已经了解深入，并且做足了功课。

这就要求我们在做线上操作之前要心细，要有详细的操作步骤，有想尽的回滚方案，做完备的测试。这些做完了以后，你的胆子才能“大”起来，胆大是因为你心中有底，心中有自信。这些自信都是前面你做功课带给你的。

出现问题本身并不可怕，可怕的是选择逃避。我们要做的就是正视问题，吸取教训，勇于担当。做好case study，防止团队在同一个地方跌倒两次。

看过同事发的一个朋友圈很有感触，在没有人注意的地方也不懈怠、不偷懒的精神，才是真正的工匠精神。作为DBA也同样非常需要这种精神，对于遗留问题的跟进不能偷懒；对于备份异常的巡检不能偷懒；对于技术的积累不能偷懒。工匠精神是我们DBA在做日常管理工作不可缺少的精神。

有句话说得好：我们之所以经常犯错，就是因为我们做的功课不够。如果你有很多功课落下了，请安排时间逐步补上，要坚信一切都是闲谈中求来，热闹中使用。