排查网站数据存储故障

■河南 刘进京

某单位的Web服务器使用的是LNMP架构，采用CentOS 7.X系统，在其上运行公司的网站。为了便于和客户交流，在其中提供了留言板模块，最近却出现了比较奇怪的问题。

当用户试图在其中添加各种信息，并上传文件等内容时，出现诸如“上传失败，服务器错误”等的提示信息，但是网站却可以正常访问。Web服务器的运行看起来比较正常，监控程序也没有收到相关的报警信息。

故障排查

对于这种情况，最直观的判断是数据库出现故障，或是磁盘空间耗尽的问题。因为提交的数据最终是保存到磁盘中的，如果磁盘存在问题，自然会造成上述故障。

进入“/usr/local/mysql/data”路径，使用“tail-f xxx.log”之类的命令查看MySQL相关日志信息，没有发现可疑信息，这说明MySQL数据库本身不存在明显的问题。进入Tomcat的运行路径下的“logs”目录，执行“tail-f catalina.out”命令，发现存在“Java.lang.RuntimeException:Can not make directory:file:/web/data/html/xxx”的提示，说明在指定的目录下无法创建文件，该目录就是网站的存储路径。

进入到该目录，执行“mkdir”命令，随便建立一个目录进行测试，显示“cannot create directory:Readonly file system”信息，这说明该路径所在的分区出现了故障，导致无法写入数据。执行“dmesg | more”命令，显示sdb1分区出现“Remounting filesyatem read-only”警告，该磁盘设备挂载在上述“/web/data/”路径下。但是MySQL的数据是保存在其他分区中的，该分区处于正常状态，所以MySQL是可以正常运行的，不会产生错误信息。但当用户上传文件时，因为文件保存在“/web/data/html”目录下，因为该目录对应的分区是只读的，所以操作无法进行。

磁盘分区之所以出现只读故障，可能由多种原因造成。EXT4、XFS等常用的文件系统拥有很强的自动修复功能，对于简单的磁盘故障，系统可以自动修复。当遇到比较严重的问题，例如当大量读写数据时突然掉电等，就会造成无法修复。系统为保证数据的一致性，会暂时屏蔽文件系统的写操作，将文件系统变成只读状态，就会造成无法写入数据的问题。

该Web服务器采用的是XFS文件系统，是日志文件系统，可以有效解决因为各种原因造成的元数据不一致的问题。其原理是在进入文件系统写操作时，会进行一系列的步骤来实现。例如，在inode中添加指向数据块指针，从Data Block Bitmap中分配数据库，将数据写入数据库等。XFS文件系统会将这些环节预先记录下来，并保存在Journal日志空间，只有日志保存完成后才会执行实际的写操作，即将元数据和用户数据写入磁盘中。

在写入过程中如果出现故障，当再次挂载文件系统时，只需重新执行之前保存的日志，就可以有效保证数据的一致性。该过程会通过Mount命令迅速完成，当然这只能应对简单的文件系统故障。对于严重的故障，只能使用fsck，xfs_repair等文件系统检测程序来解决。使用这些工具，不仅仅是执行简单的Journal Replay操作，而是对文件系统进行深度的检测，检测对象包括所有的存储文件元信息的inode区域、超级区块SuperBlock、目录等对象。

故障修复

对于CentOX 7.X来说，使用的是XFS文件系统，使用xfs_check命令，虽然可以对XFS文件系统进行检测，但其执行的速度太慢。相比之下，使用xfs_repair命令则效率要高的多。在执行修复操作之前，最好对需要修复的分区进行备份。

例如，执行“mount-o ro,norecovery/dev/sdb1/destpath”命令，以只读的方式将目标分区加载到指定路径。执行“xfsdump-f /usr/data/backupfile/destpath-L part_dump-M part_dump”命令，将该分区的数据备份到“/usr/data/backupfile”文件中，“-L”参数指定备份会话标签，“-M”参数指定设备的标签。执行“xfs_repair/dev/sdb1”命令，开始对目标分区进行修复操作。

根据提示信息，可以看到修复过程实际上分为7个步骤，当修复完成后，执行“mount /dev/sdb1 /destpath”命令，来挂载目标分区，执行“xfsrestore-f/usr/data/backupfile”命令，将备份的数据恢复到目标分区中。这样，就将该分区恢复到了正常的状态。如果执行“xfs_repair-n/dev/sdb1”命令，表示仅仅对文件系统进行检查操作，不修改文件系统任何数据。如果在加载分区时出现失败，说明XFS文件系统的Journal Replay动作出错，很可能Journal日志已经损坏，这说明错误难以正常恢复。可以执行“xfs_repair-L/dev/sdb1”命令，来清除Journal Log信息。当然，清除日志存在风险，在之前最好对目标分区进行备份。

顺便说一下，如果采用的是EXT4文件系统，分区只读故障修复方式是不同的。首先执行“tune2fs-c 0-i 0/dev/sdb1”命令，禁止重启后执行全面检测操作，否则重启时间会过长。执行“fuser-m/dev/sdb1”命令，检测哪些进程正在使用该分区，之后关闭相关进程。执行“umount/web/data”命令，卸载故障所在磁盘分区。执行“fsck-y/dev/sdb1”命令，对目标分区进行修复，修复时间的长短取决于磁盘容量和文件系统损坏程度。如果无法修复，可以根据需要选择是否执行删除操作，被删除的文件保存在对应分区挂载点的lost+found目录。修复完成后，执行“mount/dev/sdb1/web/data”命令，完成挂载操作。