今天给一个久未维护的服务器升级新发布的 WordPress 4.7，发现「数据库连接错误」。SSH 登录服务器才发现 Mariadb 已经停止运行了。后来发现是因为磁盘空间已满造成的。头一回碰到这样的问题，记录一下。

虽然我自己的 VPS 已经运行 CentOS 7 了。但是因为不方便，所以一直没有给这个服务器做升级，到现在它还运行的是 CentOS 6。登录服务器之后，先是检查 mysqld 服务。

# service mysqld status

发现它停止运行了。可惜忘记做错误记录了 :P

然后尝试启动，

# service mysqld start

自然是无法启动。

MariaDB 的日志记录显示如下。

161207 15:03:32 InnoDB: The InnoDB memory heap is disabled
161207 15:03:32 InnoDB: Mutexes and rw_locks use GCC atomic builtins
161207 15:03:32 InnoDB: Compressed tables use zlib 1.2.3
161207 15:03:32 InnoDB: Using Linux native AIO
161207 15:03:32 InnoDB: Initializing buffer pool, size = 128.0M
161207 15:03:32 InnoDB: Completed initialization of buffer pool
161207 15:03:32 InnoDB: highest supported file format is Barracuda.
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
161207 15:03:32  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
161207 15:03:32  InnoDB: Waiting for the background threads to start
161207 15:03:33 InnoDB: 5.5.40 started; log sequence number 1625628
161207 15:03:33 [Note] Recovering after a crash using mysql-bin
161207 15:03:33 [ERROR] Error in Log_event::read_log_event(): 'read error', data_len: 199, event_type: 2
161207 15:03:33 [Note] Starting crash recovery...
161207 15:03:33 [Note] Crash recovery finished.
07:03:33 UTC - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed, 
something is definitely wrong and this may fail.

搞不定 MariaDB，试试看能更新系统不，

# yum update
rpmdb: PANIC: fatal region error detected; run recovery
error: db3 error(-xxxxx) from dbenv->open: DB_RUNRECOVERY: Fatal error, run database recovery
error: cannot open Packages index using db3 - (-xxxxx)
error: cannot open Packages database in /var/lib/rpm
CRITICAL:yum.main:

Error: rpmdb open failed

yum 指令运行失败，系统也无法更新。

这可难倒我了，系统维护对我来说只能依葫芦画瓢，自己搞简直没头绪。

顺手检查一下磁盘，

# df -h
Filesystem            Size  Used Avail Use% Mounted on
tmpfs                 1.9G     0  1.9G   0% /dev/shm

似乎有什么不对劲。居然只有 tmpfs 在。那我的主磁盘呢？硬盘故障了？没硬盘了这系统还在顽强的运行着。如果打开不需要数据库的页面，居然还能正常显示。

可是… ls 指令还是能显示文件系统的目录 \o/ 重新挂载磁盘试试看，

# mount -o remount /

也是出错了。

然后试试查看磁盘占用，

# du -sh /
50G    /

嗯，好像我当初给根分区只分了 50GB 的空间。也就是说没空间了 \O/

赶紧检查了一番，才发现因为时间太久，让一些记录和临时文件占满了磁盘空间。稀奇的是，尽管主分区不见了，但是我还是可以删除那些显示出来的文件。清理这些文件之后，在重新挂载根分区试试，

# mount -o remount /

哦哦哦，居然成功了，

# df -h
Filesystem            Size  Used Avail Use% Mounted on
tmpfs                 1.9G     0  1.9G   0% /dev/shm
/dev/mapper/vg_pec-lv_root
                       50G  7.1G   40G  16% /

然后启动 mysqld 服务试试看，

# service mysqld start
Starting mysqld:                                           [  OK  ]

这下子顺利的启动了。

然后 rpm 的问题还需要单独修复。幸好这里有现成的方法：

1. 先备份一下 /var/lib/rpm/ 文件夹中的文件，将它们复制到备份文件夹，

   mkdir /root/backups.rpm.yyyymmdd/
   cp -avr /var/lib/rpm/ /root/backups.rpm.yyyymmdd/

2. 然后尝试修复：删除旧的 db 文件，验证数据库，然后重建数据库，最后清理缓存，

   # rm -f /var/lib/rpm/__db*
   # db_verify /var/lib/rpm/Packages
   # rpm --rebuilddb
   # yum clean all

3. 试试看能升级了不，

   # yum update

看来需要给服务器加个提醒，磁盘占用达到 90% 以上的时候给我发封邮件提示一下。创建包含下面内容的 check_disk_vol.sh：

# check free disk everyday
q=$(df -h | grep '50G' | awk '{print $4}' | awk -F\% '{print $1}')
if [ "$q" -gt "90" ] ; then
    mail -s "PEC VPS Warning: Disk used more than 90%" my_mail@my_mail.tld < /dev/null
fi

然后将此文件加入到计划任务，

echo "0 3 * * * root sh ~/sh/check_disk_vol.sh > /dev/null 2>&1" >> /etc/crontab

让它每天早上 3 点钟执行一次检查。

让我这种二把刀管理服务器真是一件很危险的事情。幸好这次的问题不是太严重，很容易就恢复正常了。不然还不知道要折腾成什么样呢。©

本文发表于水景一页。永久链接：<https://cnzhx.net/blog/disk-offline-because-full-on-a-server-with-centos-6/>。转载请保留此信息及相应链接。