【StoneDB】故障信息收集FAQ

数据库实例crash了该怎么办？

数据库实例crash可能发生的原因：

1）系统负载高
2）硬件故障
3）数据页损坏
4）Bug
需要收集的日志：
1）操作系统的日志，默认路径在/var/log/messages
2）StoneDB的error日志，默认路径在/stonedb/install/log/mysqld.log
3）StoneDB的trace日志，默认路径在/stonedb/install/log/trace.log
如果操作系统日志、error日志和trace日志的信息不足以分析数据库实例crash的原因，需要开启core dump。开启core dump后，当数据库实例再次发生crash时，会生成core dumpfile，用gdb分析生成的core dumpfile。

数据库实例挂起了该怎么办？

数据库实例挂起可能发生的原因：
1）系统负载高
2）连接数满
3）磁盘空间满
4）MDL锁等待
5）Bug
需要收集的日志：
1）查看连接数是否满了
如果连接数超过参数max_connections的阀值，新的连接是无法连接数据库实例的。
2）查看磁盘空间是否满了
如果磁盘空间满了，DML产生的binlog是无法写入磁盘文件的。
3）查看是否有锁等待
如果show processlist有大量"Waiting for table metadata lock"等待的返回，需要找到阻塞者，并kill阻塞者。
4）收集mysqld进程的堆栈
如果进程处于假死、死循环状态时，pstack可以跟踪进程的堆栈。在一段时间内，多执行几次pstack，如果堆栈总停留在同一个位置，这个位置就特别需要关注，很可能就是出问题的地方。
pstack在抓取进程的堆栈时会触发一个SIGSTOP信号（类似发出kill -19命令），实际上pstack调用的是gdb的命令。gdb通常会发起SIGSTOP信号来停止进程的运行，因此在生产环境执行pstack命令的时候一定要格外小心，因为可能会导致应用服务停止运行一小会儿。
输出所有线程堆栈的信息：pstack mysqld_pid >> mysqld_pid.log