检查 MySQL 数据库的启动时间
Linux 系统中的 systemd 会在 mysqld 进程 crash 后自动重新启动 MySQL 的服务,需要注意的是使用 kill -9 杀死 mysqld 进程系统会自动重新启动,而只使用 kill 命令则不会重新启动,因为执行 kill 命令,系统会发送一个 SIGTERM 信号给 mysqld,mysql 数据库会正常关闭,日志中会出现类似下面的记录:
2020-10-26T09:06:48.435181Z 0 [System] [MY-010910] [Server] /usr/sbin/mysqld: Shutdown complete (mysqld 8.0.19) MySQL Community Server - GPL.
MySQL 数据库 crash 后都会重新启动,因此我们有时可能不知道 MySQL 数据库已经 crash 过了,但我们可以从mysql数据库启动时间上找到线索,下面介绍四种检查 MySQL 数据库启动时间的方法。
检查 MySQL 服务状态
scutech@scutech:~$ service mysql status
● mysql.service - MySQL Community Server
Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2020-10-21 05:54:18 NDT; 4 days ago
Process: 774 ExecStart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid (code=exited, status=0/SUCCESS)
Process: 708 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
Main PID: 791 (mysqld)
Tasks: 27 (limit: 2328)
CGroup: /system.slice/mysql.service
└─791 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid
显示 MySQL 数据库已经运行 4 天多。
检查 MySQL 中的 uptime 状态
mysql> show global status like 'uptime';
+---------------+--------+
| Variable_name | Value |
+---------------+--------+
| Uptime | 428334 |
+---------------+--------+
1 row in set (0.32 sec)
这个值是以秒为单位,下面换算成以天为单位是 4 天多。
mysql> select 428334/60/60/24;
+-----------------+
| 428334/60/60/24 |
+-----------------+
| 4.957569444444 |
+-----------------+
1 row in set (0.01 sec)
查询 uptime 状态的另一种方法是使用 mysqladmin version 或在 mysql 客户端里用 “s” 进行查询。
使用 ps 检查进程启动时间
使用 ps 命令查询发现 mysqld 启动了4天23小时3分种54秒
scutech@scutech:~$ ps -eo pid,user,args,etime|grep mysqld
791 mysql /usr/sbin/mysqld --daemoniz 4-23:03:54
检查 MySQL 日志
找关键字 “ready for connections”,可以查到启动信息。
2020-10-21T08:24:18.986765Z 0 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.7.28-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 MySQL Community Server (GPL)
MySQL 数据库 crash 的常见原因
MySQL 数据库 crash 的最常见原因有两个,一个是 mysql 的 bug , 另一个是 mysql 申请系统资源失败。
MySQL 的 bug
MySQL数据库 crash 的最常见的一个原因当然是 MySQL 的bug。95% 的 bug 都是和具体的 sql 相关,通常是 MySQL crash 前执行的最后一个 sql 有问题,因此定位 bug 时应打开 general query log ,根据最后一个 sql 来查找线索。
当你确定了 crash 的原因后,应该检查一下 MySQL 的 bug 库(https://bugs.mysql.com),通常采用 Advanced search,看看有没有类似的问题。如果你找到了可能与你相关的 bug,确认它是否修复了。如果已经修复了,那么把 MySQL 升级到 bug 已经修复的版本。
在每个版本的 Release Notes 里面有一节 Bugs Fixed ,可以查到修复的 bug 。