中止MySQL会话的方法与部分高危操作
2013-04-25 21:00:25 
阿炯
本文盘点了在日常运维过程觉的中止MySQL会话的方法，与部分高危操作，为大家提供一个相关参考。中止MySQL会话
方法一
通过information_schema.processlist表中的连接信息生成需要处理掉的MySQL连接的语句临时文件，然后执行临时文件中生成的指令。
mysql> select concat('KILL ',id,';') from information_schema.processlist where COMMAND='Sleep';
+------------------------+
| concat('KILL ',id,';') |
+------------------------+
| KILL 2158100; |
| KILL 2155181; |
......
| KILL 1317283; |
| KILL 1243834; |
+------------------------+
21 rows in set (0.01 sec)
#将那些'闲置'的查询进程kill
mysql>select concat('KILL ',id,';') from information_schema.processlist where COMMAND='Sleep' into outfile '/tmp/kill.txt';
#将那些处于锁定状态的进程kill
mysql>select concat('KILL ',id,';') from information_schema.processlist where State='Locked' into outfile '/tmp/kill.txt';
Query OK, 2 rows affected (0.00 sec)
mysql>source /tmp/kill.txt;
Query OK, 0 rows affected (0.00 sec)
方法二
杀掉当前所有的MySQL连接
mysqladmin -uroot -p processlist|awk -F "|" '{print $2}'|xargs -n 1 mysqladmin -uroot -p kill
mysqladmin -S /tmp/mysqld3306.sock -p processlist|perl -F'\s' -ane'print "$F[1]\n" if($F[1]=~/\d+/)'
杀掉指定用户运行的连接，这里为'webserver'
mysqladmin -uroot -p processlist|awk -F "|" '{if($3 == "webserver")print $2}'|xargs -n 1 mysqladmin -uroot -p kill
mysqladmin -uroot -p processlist|perl -F'\s' -ane'print "$F[1]\n" if($F[3] eq 'webserver')'|mysqladmin -uroot -p kill
方法三
通过SHEL脚本实现
#杀掉锁定的MySQL连接
for id in `mysqladmin processlist|grep -i locked|perl -F'\s' -alne'print $F[1]'`
do
mysqladmin kill ${id}
done
方法四
通过Percona Toolkit工具集中提供的pt-kill命令进行
#杀掉超过180秒的sql
pt-kill -busy-time 180 -kill
#如果只是想看有哪些sql运行超过180秒
mk-kill -busy-time 180 -print
#如果你想杀掉，同时输出杀掉了哪些进程
mk-kill -busy-time 180 -print –kill
高危操作
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 不使用索引，导致全表扫描。
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.犯困时操作线上环境
复杂操作需要制定好操作步骤，需要第二人协助确认和检查。
小结
虽然目前很多数据库管理已经逐步进入半自动化，脚本化。但很多时候还需要人为操作，需谨慎。虽做到万无一失很难，但做好备份，准备工作，环境允许甚至测试验证都是必不可少的。