MySQL 运维高危操作

实际工作中，经常遇到一些临时应急需求，DBA没有充分准备之前，直接到线上执行一些命令，除此之外一些没有考虑清楚厉害关系的命令，最后导致事故的情况。

MySQL DBA运维中那些动作属于危险性操作?

MySQL数据库操作：

1. shutdown/restart命令（8.0版本）: 关闭 mysql服务,重新启动，

• 平时在运行习惯，在测试环境随意执行，到生产无意识执行这些命令。
• 大事务运行还没结束，执行命令导致事务大量回滚 或 无法数据库及时关闭问题。如load 等操作中

2. kill pid进程

不是马上kill掉进程，底层要进行回滚动作，要是大事务 回滚需要很长时间 30分钟，3个小时或更长。

• 碰到大事务下，kill操作
• 服务器负载过高，无法提供足够的CPU，IO等资源

3. FLUSH BINARY LOGS:

截断旧binlog日志，产生新的binlog日志，同事也会触发expire_logs_days参数清除过期binlog，在高可用架构下禁止执行。

• 从库因为其他问题，日志还有没分发到从库relay log中
• 正好进行大事务，截断操作，可能导致，数据库穷住。

binlog记录的是数据操作记录，被清除，在出现故障无法进行恢复

4. set sql_log_bin=0

SESSION操作不记录binlog，当然一些特殊情况，不想分发到从库，比如从库要额外创建一些索引之类的。

• 相关操作无法分发到从库上

5. RESET MASTER / RESET SLAVE :

重置主节点，从节点信息

• gtid重置，
• binlog 信息清除 或
• 重置复制信息

6. TRUNCATE TABLE

清除数据，

• 不会记录binlog 恢复找到操作详细数据
• 处置之外truncate 有一定的概率触发bug ，穷住库

7. DROP DATABASE

删除数据和文件

• binlog 不会记录详细数据操作
• 底层数据和结构文件，全部物理删除

8. FLUSH TABLES。。。(FLUSH TABLES WITH READ LOCK):

• 关闭所有打开的表
• 强制关闭所有正在使用的表
• 并刷新查询缓存和预准备语句缓存
• 不会刷新脏块
• 上全局COMMIT锁

9. LOCK TABLES READ/WRITE ;

锁表动作

10. ALTER DATABASE dbname READ ONLY（8.0版本）

对于数据库只读，不允许写

11. slave_skip_errors ：

跳过复制错误代码，导致主从数据不一致

12. purge binary logs

清除binglog物理文件，复制状态下，需要确保无用的binlog进行清除。

13. DML操作条件写错 或 不使用索引

• where 不使用索引，导致全表扫描
• insert into t1 select * from t2方式：t1 或 t2 表结构变化导致语句失败。

14. 在线DDL

不管online ddl 还是 pt-osc ，gh-ost都会有一定的问题存在，所以谨慎执行，特别是高负载下。

• online ddl 导致meta data lock
• pt-osc 因为表数量大导致中间意外停止，触发器无法删除
• gh-ost binlog接受，延迟导致一直无法进行下去。

15. ANALYZE ，OPTIMIZE table

• 锁表，缓存移除，对表数据无法进行修改，严重的话会影响业务。

15. MySQL无备份、无高可用节点，binlog没有开启（ROW）模式

• 故障触发，一些操作 都无法回逆。这种环境更应该谨慎

16. 执行rm -rf / data tmp 等类似操作，执行rm 前要三思

• 物理删除，进程在虽然可以通过lsof delete方式召回，但未必能全部恢复。

17. 不用mysqld_safe守护进程启动, 执行kill mysqld pid 等操作

• 没有守护进程，mysql服务器会异常关闭，无法启动。更严重情况下数据文件损坏，无法启动

18. 在生产环境执行测试命令。

19. 逻辑恢复数据，实例不对（基于IP连接管理环境）

• 特备是开发工具Navicat，SQLyog，这部分权限需要控制好。
• 执行数据操作命令需要核对实例信息

20. 空间不够下的操作

导致导致事务丢失，文件损坏，比如备份，迁移数据文件等操作。

21. 从库延迟并对外提供服务

数据延迟，导致业务段收到的信息不对。因为mysql是逻辑回放。

22. 开多窗口操作重要数据库

容易把命令 分发到所有节点。

23. 敏感字段不加密，线上数据同步到线下

敏感数据无法做到透明，但可以通过一些函数算法，替换一些字段。

24. 系统表操作

对mysql库 ，information_schema库下的表进行删除，更改，创建，truncate 动作，都有可能导致数据库无法启动。

25.参数更改

• lower_case_table_names大小写敏感，只能初始化设置，之后不建议改。需要改动就逻辑导出导入方式
• innodb_buffer_pool_size 在线调整，当负载高的时候容易出现持续穷住现象。

26.犯困时操作线上环境

• 复杂操作需要制定好操作步骤
• 需要第二人协助确认和检查

总结

虽然目前很多数据库管理已经逐步进入半自动化，脚本化。但很多时候还需要人为操作，需谨慎。虽做到万无一失很难，但做好备份，准备工作，环境允许甚至测试验证都是必不可少的。