引言

最近博客又抽風了，打開主頁后提示 Error Establishing a Database Connection 。仔細想想，應該就是數(shù)據(jù)庫服務器 mariadb 掛了；以前也遇到過類似的問題。經(jīng)過分析日志，并結合網(wǎng)上的資料最終解決了問題。

日志

以下是 mariadb 服務器掛掉時的比較關鍵的日志信息，從下面的日志信息中，我們可以很容易地看出由于內存不足，從而導致數(shù)據(jù)庫服務器啟動時崩潰。

InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
160919  2:47:12  InnoDB: Waiting for the background threads to start
160919  2:47:13 Percona XtraDB (http://www.percona.com) 5.5.46-MariaDB-37.6 started; log sequence number 352718445
160919  2:47:13 [ERROR] mysqld: Out of memory (Needed 128917504 bytes)
160919  2:47:13 [Note] Plugin 'FEEDBACK' is disabled.
160919  2:47:13 [Note] Server socket created on IP: '0.0.0.0'.
160919  2:47:13 [Note] Event Scheduler: Loaded 0 events
160919  2:47:13 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.5.47-MariaDB'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  MariaDB Server
160919 02:47:35 mysqld_safe Number of processes running now: 0
160919 02:47:35 mysqld_safe mysqld restarted
160919  2:47:35 [Note] /usr/libexec/mysqld (mysqld 5.5.47-MariaDB) starting as process 28614 ...
160919  2:47:35 InnoDB: The InnoDB memory heap is disabled
160919  2:47:35 InnoDB: Mutexes and rw_locks use GCC atomic builtins
160919  2:47:35 InnoDB: Compressed tables use zlib 1.2.7
160919  2:47:35 InnoDB: Using Linux native AIO
160919  2:47:35 InnoDB: Initializing buffer pool, size = 128.0M
InnoDB: mmap(137756672 bytes) failed; errno 12
160919  2:47:35 InnoDB: Completed initialization of buffer pool
160919  2:47:35 InnoDB: Fatal error: cannot allocate memory for the buffer pool
160919  2:47:35 [ERROR] Plugin 'InnoDB' init function returned error.
160919  2:47:35 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
160919  2:47:35 [ERROR] mysqld: Out of memory (Needed 128917504 bytes)
160919  2:47:35 [ERROR] mysqld: Out of memory (Needed 96681984 bytes)
160919  2:47:35 [ERROR] mysqld: Out of memory (Needed 72499200 bytes)
160919  2:47:35 [Note] Plugin 'FEEDBACK' is disabled.
160919  2:47:35 [ERROR] Unknown/unsupported storage engine: InnoDB
160919  2:47:35 [ERROR] Aborting

解決

在使用 free -m 查看內存信息時，發(fā)現(xiàn) swap 分區(qū)大小為 0。難怪說數(shù)據(jù)庫服務器無法啟動呢，在內存不夠用的情況下，又無法使用 swap 分區(qū)，自然崩潰了。由于 VPS 使用了 SSD，性能自然不錯。下面我們給服務器系統(tǒng) CentOS 7 添加 1024M 的 swap 分區(qū)，采用的方法是創(chuàng)建一個 swap 文件：

使用下面的命令創(chuàng)建 swapfile ：

# 1048576 = 1024 * 1024
dd if=/dev/zero of=/swapfile bs=1024 count=1048576

使用下面的命令配置 swap 文件：

mkswap /swapfile

接下來，使用下面的命令立即啟用 swapfile ，這樣就不用等到下次重啟時自動啟用：

swapon /swapfile


最后，我們在 /etc/fstab 中添加下面一行，這樣可以在系統(tǒng)下次重啟時自動生效創(chuàng)建的 swapfile ：

/swapfile       swap    swap defaults   0 0


使用 cat /proc/swaps 或 free -m 查看 swapfile 的生效情況，如下圖所示：

在完成上面的步驟后，我們還可以在 /etc/my.cnf 配置文件中添加一些配置信息，降低 mariadb 資源需求，具體的配置請參考文末給出的鏈接。

啟動

啟動 apache 服務器： systemctl start httpd.service ；
啟動 mariadb 服務器： systemctl start mariadb.service 。
啟動完成后，再次打開網(wǎng)站主頁，bingo，問題解決了！

總結

低配 VPS 最好還是要多增加 swap 分區(qū)大小，尤其對于使用 SSD 的 VPS 而言， swap 分區(qū)的性能也非常不錯；
數(shù)據(jù)庫服務器崩潰后，一定要記得學會分析日志。最簡單的做法就是使用 tail 命令看看最近的崩潰日志，并根據(jù)崩潰信息尋找解決問題的辦法；

WordPress 程序本身比較占資源，所以運行在低配的 VPS 時，還是需要做些優(yōu)化工作。具體請參考文末給出的鏈接。