一起故障引发的线上MySQL数据库权限分级以及数据库实例大小限制

其实我们最初管理MySQL数据库权限管理和数据库实例大小预估是没有经验，也比较粗糙的。在此之前这方面经验比较欠缺。自从有了那起线上故障后，我们对线上数据库管理权限进行了分级。同时从规范上要求DBA必须使用不同的管理用户来维护数据库。对于数据库实例大小，由于是从Oracle转过来的，之前没有太多概念。这次故障后有了深入的理解和改进。

三年前的某天，一位DBA在做线下支持工作的时候，不小心把应该在线下执行的truncate脚本执行到了线上，导致一个700G大小的MySQL数据库大部分大表被清理了，还好这个库是一个小众的库，影响的业务范围不大。不过还是要在当天恢复数据。

这里暴漏几个问题：
1、流程不规范，数据清理直接truncate。
2、线上线下环境未明显区分。
3、手工同步数据，有出问题的风险。
4、单表数量太大，其中一个表300G+。
5、没有针对误操作的备份类型，只有全实例备份。

那段时间有两个MySQL DBA新入职，我们四个人一起开始这个数据库实例的恢复操作。恢复步骤如下：
1、先把其中一个从库的同步停止下来，保留一个现场，同时把主库read only，告知用户数据异常需要恢复。
2、通知RD，这个数据库数据误操作现在丢了，告诉他大概恢复要4-5小时，请RD挂一个通知，并通知PM。
3、分配任务，A去查看最近的热备份，B去确认热备份恢复流程是否正常，C根据备份恢复流程准备简易恢复脚本。
4、判断恢复方式，是在数据库服务器上恢复，还是存储机上恢复，我们是用nfs方式备份的。需要做决定。最终决定使用一个新的服务器来恢复，这个决定后来被证明是错误的。
5、开始建实例、应用日志、恢复等步骤，在进行数据库备份文件拷贝的时候发现由于运维部的限制，我们机器之间的文件传输速度太慢了，只有40M左右，MySQL的恢复不支持并行，也就是说拷贝文件完成，要接近5个小时。这个结果是不能接受的。简单商量了一下，决定改方案，直接在存储上起实例恢复，这样可以节约大量拷贝文件的时间。
6、根据在线库的环境在存储上创建了数据库实例，开始恢复的步骤，进展一切顺利。
7、开始应用Binlog日志延迟的时候出了一个外键冲突的报错，根据报错我们判断是由于这套库里有外键，而MySQL5.5应用日志是串行的，导致有些数据不完整，恢复无法进站下去，这个时候需要做一个决定，是换个方式恢复，还是直接把恢复出来库的外键删除掉，使恢复可以继续。经过判断后我们认为删除外键是可以的，我们将已恢复数据库的外键删除。
8、日志终于应用到误操作之前了，数据访问正常。和线上的残留数据对比之后我们确认这个数据已经到达误操作之前了。我们将当时线上数据备份一份后，用存储上的数据覆盖了线上数据。
9、通知RD数据恢复成功，请RD验证服务是否异常。
10、第二天确认是否有客户投诉，经确认只有一起客户投诉，不是关于数据的，是前一天我们恢复过程中系统访问不正常的。证明我们数据恢复成功。

针对这次故障，我们做了深刻的总结，并就下面事项达成了一致：
1、对线上的DBA管理账户进行分级，默认登录的管理账号没有任何drop权限，以避免大规模数据误操作，要登录超级用户权限，需要输入特殊参数。所有数据库都创建管理只读账号，普通登录用只读账号。我们对账户分级之后，没有再出现过误删除数据和误删除表的误操作。
2、推进数据库实例大小的限制和表大小限制规范，推出开发规范，以避免单实例、单表数据量太大，我们将常规数据库实例规范在150G，变长字段表单表500w。
目前我们的数据库实例大部分都控制在100G以内。个别OLAP类和日志类较大。
3、线下数据同步必须使用同步工具，不能手工同步。开发了针对表、库、实例的同步工具。
4、针对线上核心数据以及和资金相关的数据，与RD沟通做定制备份，可以恢复到半年内每一天。
5、线上数据库和线下数据库主机名严格区分。

由这次故障引发流程、制度、工具等的变更结果一直伴随我们的维护工作到今天。故障驱动，有时会能带来意想不到的效果。