来源： chinaunix 博客
原文链接：http://blog.chinaunix.net/uid-20639775-id-5765237.html
专职做 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 工具获取，再加以分析，也可以通过如下两个工具来实时查看：
针对数据安全，主要包含如下几个部分：
在权限方面，我们经常会看到有很多的数据库根本就没有密码，或者给业务的用户使用完全的权限（all privileges），或者是给某个帐号可以从任何地方登录的权限，这些都是非常致命的。
建议在授予权限的时候注意如下几点：
-
数据库一定设置符合密码复杂度的用户密码。
-
禁止给用户设置 % 的登录机器。
-
只给业务最小权限的帐号，并限制登录的机器。
目前一般都是主从架构，主从的数据是否一致？90% 以上的主从架构都缺乏数据一致性校验，之前遇到主从切换后数据不一致的情况，导致线上故障。
为了保证数据的一致性，记得周期性地使用 pt-table-checksum 来检查主从数据是否一致，如果不一致，可以使用 pt-table-sync 进行修复。
做为 DBA，经常要思考，如果数据被误删，在现有的环境下是否会导致数据丢失。如果会，那就是你 DBA 工作没有做到位。
主要考虑的指标为：
这里主要考虑三件事情：
