引言
最近博客又抽風了，打開主頁後提示 Error Establishing a Database Connection 。仔細想想，應該就是數據庫服務器 mariadb 掛了；以前也遇到過類似的問題。經過分析日志，並結合網上的資料最終解決了問題。
日志
以下是 mariadb 服務器掛掉時的比較關鍵的日志信息，從下面的日志信息中，我們可以很容易地看出由於內存不足，從而導致數據庫服務器啟動時崩潰。
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 查看內存信息時，發現 swap 分區大小為 0。難怪說數據庫服務器無法啟動呢，在內存不夠用的情況下，又無法使用 swap 分區，自然崩潰了。由於 VPS 使用了 SSD，性能自然不錯。下面我們給服務器系統 CentOS 7 添加 1024M 的 swap 分區，采用的方法是創建一個 swap 文件：
使用下面的命令創建 swapfile ：
# 1048576 = 1024 * 1024 dd if=/dev/zero of=/swapfile bs=1024 count=1048576
使用下面的命令配置 swap 文件：
mkswap /swapfile
接下來，使用下面的命令立即啟用 swapfile ，這樣就不用等到下次重啟時自動啟用：
swapon /swapfile
最後，我們在 /etc/fstab 中添加下面一行，這樣可以在系統下次重啟時自動生效創建的 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 。
啟動完成後，再次打開網站主頁，bingo，問題解決了！
總結
低配 VPS 最好還是要多增加 swap 分區大小，尤其對於使用 SSD 的 VPS 而言， swap 分區的性能也非常不錯；
數據庫服務器崩潰後，一定要記得學會分析日志。最簡單的做法就是使用 tail 命令看看最近的崩潰日志，並根據崩潰信息尋找解決問題的辦法；
WordPress 程序本身比較占資源，所以運行在低配的 VPS 時，還是需要做些優化工作。具體請參考文末給出的鏈接。
