《數據和云》 公眾號:MySQL 數據庫崩潰（crash）的常見原因和解決辦法

文章目錄

• 檢查 MySQL 數據庫的啟動時間
• • 檢查 MySQL 服務狀態
  • 檢查 MySQL 中的 uptime 狀態
  • 使用 ps 檢查進程啟動時間
  • 檢查 MySQL 日志
• MySQL 數據庫 crash 的常見原因
• • MySQL 的 bug
  • MySQL 申請系統資源失敗或內存泄漏
  • MySQL 內存占用的計算
• MySQL 客戶端的內存泄漏
• 文章下方是我的微信，歡迎加我。👇

檢查 MySQL 數據庫的啟動時間

Linux 系統中的 systemd 和 mysqld_safe 會在 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 ServerLoaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)Active: active (running) since Wed 2020-10-21 05:54:18 NDT; 4 days agoProcess: 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 mysqld791 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 。

MySQL 申請系統資源失敗或內存泄漏

內存不足或 MySQL 申請系統資源失敗外都會造成 MySQL 崩潰，例如磁盤空間滿了，磁盤上的文件 corrupt 等。此時需要定位 crash 的根本原因有下面幾種方法：

仔細閱讀 MySQL 的錯誤日志，這個日志里面的一些程序調試信息看起來很讓人困惑，但靜下心來仔細看，很多時候會找到線索；

打開 general query log ，找到最后一個 sql 訪問的表或索引，檢查這個表或索引，如果有問題就重建，通常可以解決問題。

使用 strace、pstack、pmap、gdb 分析 mysqld 的代碼，可能需要打開 core dump；

使用 CMake 的選項 -DWITH_DEBUG=1 重新編譯 mysqld，然后運行重新編譯后的 mysqld，查看 trace 文件、error log 進行排錯。

MySQL 內存占用的計算

全局內存
innodb_buffer_pool_size innodb_log_buffer_size thread_cache_size table_open_cache table_definition_cache key_buffer_size
線程內存
binlog_cache_size thread_stack
單次操作內存
join_buffer_size read_buffer_size read_rnd_buffer_size tmp_table_size sort_buffer_size

計算公式
MySQL 8 中最大內存占用參考值計算公式：

SELECT ( @@innodb_buffer_pool_size + @@innodb_log_buffer_size + @@key_buffer_size + @@max_connections * (@@binlog_cache_size + @@thread_stack + @@read_buffer_size + @@read_rnd_buffer_size + @@sort_buffer_size + @@join_buffer_size + @@tmp_table_size ) ) / 1024 /1024 AS MAX_MEM_MB;

innodb_buffer_pool_size

• key_buffer_size
• max_connections*(sort_buffer_size+read_buffer_size+binlog_cache_size)
• max_connections*2MB

臨時解決可以使用下面的命令釋放緩存：

echo 1 > /proc/sys/vm/drop_caches

0：0是系統默認值，默認情況下表示不釋放內存，由操作系統自動管理
1：釋放頁緩存
2：釋放dentries和inodes
3：釋放所有緩存
從長遠看還是要修改對應的參數進行解決。

MySQL 客戶端的內存泄漏

MySQL 客戶端的內存泄漏時通常會有下面的提示

mysql: Out of memory at line 42, 'malloc.c' mysql: needed 8136 byte (8k), memory in use: 12481367 bytes (12189k) ERROR 2008: MySQL client ran out of memory

這通常是客戶端收到的返回結果集太大造成的，解決辦法有兩種：

檢查正在運行的 SQL ，看看您真的需要這么大的返回結果集嗎？

允許 mysql 時加上 --quick 選項，這會減少客戶端單次收到的返回集，但會增加 mysqld 的負載。

文章下方是我的微信，歡迎加我。👇

總結

以上是生活随笔為你收集整理的MySQL 数据库崩溃（crash）的常见原因和解决办法---发表到 《数据和云》 公众号的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。