檢查 MySQL 數(shù)據(jù)庫的啟動時(shí)間

Linux 系統(tǒng)中的 systemd 會在 mysqld 進(jìn)程 crash 后自動重新啟動 MySQL 的服務(wù)，需要注意的是使用 kill -9 殺死 mysqld 進(jìn)程系統(tǒng)會自動重新啟動，而只使用 kill 命令則不會重新啟動，因?yàn)閳?zhí)行 kill 命令，系統(tǒng)會發(fā)送一個(gè) SIGTERM 信號給 mysqld，mysql 數(shù)據(jù)庫會正常關(guān)閉，日志中會出現(xiàn)類似下面的記錄：

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 數(shù)據(jù)庫 crash 后都會重新啟動，因此我們有時(shí)可能不知道 MySQL 數(shù)據(jù)庫已經(jīng) crash 過了，但我們可以從mysql數(shù)據(jù)庫啟動時(shí)間上找到線索，下面介紹四種檢查 MySQL 數(shù)據(jù)庫啟動時(shí)間的方法。

檢查 MySQL 服務(wù)狀態(tài)

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 數(shù)據(jù)庫已經(jīng)運(yùn)行 4 天多。

檢查 MySQL 中的 uptime 狀態(tài)

mysql> show global status like 'uptime';+---------------+--------+| Variable_name | Value  |+---------------+--------+| Uptime        | 428334 |+---------------+--------+1 row in set (0.32 sec)

這個(gè)值是以秒為單位，下面換算成以天為單位是 4 天多。

mysql> select 428334/60/60/24;+-----------------+| 428334/60/60/24 |+-----------------+|  4.957569444444 |+-----------------+1 row in set (0.01 sec)

查詢 uptime 狀態(tài)的另一種方法是使用 mysqladmin version 或在 mysql 客戶端里用 “\s” 進(jìn)行查詢。

使用 ps 檢查進(jìn)程啟動時(shí)間

使用 ps 命令查詢發(fā)現(xiàn) mysqld 啟動了4天23小時(shí)3分種54秒

scutech@scutech:~$ ps -eo pid,user,args,etime|grep mysqld  791 mysql    /usr/sbin/mysqld --daemoniz  4-23:03:54

檢查 MySQL 日志

找關(guān)鍵字 “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 數(shù)據(jù)庫 crash 的常見原因

MySQL 數(shù)據(jù)庫 crash 的最常見原因有兩個(gè)，一個(gè)是 mysql 的 bug ， 另一個(gè)是 mysql 申請系統(tǒng)資源失敗。

MySQL 的 bug

MySQL數(shù)據(jù)庫 crash 的最常見的一個(gè)原因當(dāng)然是 MySQL 的bug。95% 的 bug 都是和具體的 sql 相關(guān)，通常是 MySQL crash 前執(zhí)行的最后一個(gè) sql 有問題，因此定位 bug 時(shí)應(yīng)打開 general query log ，根據(jù)最后一個(gè) sql 來查找線索。
當(dāng)你確定了 crash 的原因后，應(yīng)該檢查一下 MySQL 的 bug 庫（https://bugs.mysql.com），通常采用 Advanced search，看看有沒有類似的問題。如果你找到了可能與你相關(guān)的 bug，確認(rèn)它是否修復(fù)了。如果已經(jīng)修復(fù)了，那么把 MySQL 升級到 bug 已經(jīng)修復(fù)的版本。

在每個(gè)版本的 Release Notes 里面有一節(jié) Bugs Fixed ，可以查到修復(fù)的 bug 。

MySQL 申請系統(tǒng)資源失敗

出現(xiàn)這種現(xiàn)象通常會在 MySQL 的錯誤日志里下面的提示：

mysqld got signal 11

我們使用 perror 查看一下 11 錯誤的原因：

root@scutech:~# perror 11OS error code  11:  Resource temporarily unavailableMySQL error code MY-000011: Can't unlock file (OS errno %d - %s)

最常見的是系統(tǒng)內(nèi)存不足，由于系統(tǒng)連接數(shù)的增加和每個(gè)連接對內(nèi)存的占用增加，造成 MySQL 申請新的內(nèi)存失敗而 crash，此時(shí)錯誤日志里面通常有類似下面的記錄：

10:55:07 UTC - mysqld got signal 11 ;This could be because you hit a bug. It is also possible that this binaryor one of the libraries it was linked against is corrupt, improperly built,or misconfigured. This error can also be caused by malfunctioning hardware.Attempting to collect some information that could help diagnose the problem.As this is a crash and something is definitely wrong, the informationcollection process might fail.Please help us make Percona Server better by reporting anybugs at http://bugs.percona.com/
key_buffer_size=16777216read_buffer_size=8388608max_used_connections=95max_threads=50001thread_count=31connection_count=28It is possible that mysqld could use up tokey_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 819273023 K  bytes of memoryHope that's ok; if not, decrease some variables in the equation.

此段的記錄里面列出了內(nèi)存占用的計(jì)算方法，但需要注意這個(gè)公式里面沒有把內(nèi)存占用的大戶，Innodb 的 buffer pool 計(jì)算進(jìn)來，大家可以用這個(gè)公式加上 buffer pool 計(jì)算自己的內(nèi)存占用，然后根據(jù)自己的實(shí)際情況對各個(gè)參數(shù)進(jìn)行調(diào)整，如果連接數(shù)過多，可以通過修改 max_connections 對最大連接數(shù)進(jìn)行限制。

除了內(nèi)存不足造成 MySQL 申請系統(tǒng)資源失敗外，另一個(gè)常見的現(xiàn)象是磁盤問題，例如磁盤空間滿了，磁盤上的文件 corrupt 都會造成 MySQL crash。此時(shí)需要定位 crash 的根本原因有下面幾種方法：

1. 仔細(xì)閱讀 MySQL 的錯誤日志，這個(gè)日志里面的一些程序調(diào)試信息看起來很讓人困惑，但靜下心來仔細(xì)看，很多時(shí)候會找到線索；

2. 打開 general query log ，找到最后一個(gè) sql 訪問的表或索引，檢查這個(gè)表或索引，如果有問題就重建，通?？梢越鉀Q問題。

3. 開啟 core dump，使用 gdb 分析 core file；

4. 使用 strace 跟蹤 mysqld 進(jìn)程的系統(tǒng)調(diào)用；

5. 使用 CMake 的選項(xiàng) -DWITH_DEBUG=1 重新編譯 mysqld，然后運(yùn)行重新編譯后的 mysqld，查看 trace 文件。