乐趣区

关于fastdfs:新年上班第一天生产环境分布式文件系统崩了

jiezi

写在后面

说来也怪，早不崩晚不崩，偏偏在下班第一天的时候，生产环境分布式文件系统崩了。我才刚来到我的工位坐下，“叮铃铃”电话响了，是经营打来的，“喂，冰河，快点看看，生产环境的图片和视频都无奈上传了，零碎解体了，快点看看啊！”。你说我一个不是做运维的，间接打来电话让我看生产环境的事变？原来是运维那哥们还没下班，额，好吧，我承受了，于是我迅速整顿好工位，摆出电脑，登录服务器，一顿操作猛如虎，10 分钟搞定了，剩下的就是异步复制图片和视频了。

明天，就和小伙伴们分享下，这次生产环境分布式文件系统呈现的问题，以及我是如何 10 分钟排查问题和解决问题的。另外，本文不是基于生产环境事变写的，而是预先，我在我本机虚拟机上模仿的环境。解决问题的思路和办法都是一样的。

额，预计运维要被 3.25 了！！

文章已收录到：

https://github.com/sunshinelyz/technology-binghe

https://gitee.com/binghe001/technology-binghe

问题定位

通过登录服务器查看零碎的拜访日志，发现日志文件中输入了如下异样信息。

org.csource.common.MyException: getStoreStorage fail, errno code: 28
    at org.csource.fastdfs.StorageClient.newWritableStorageConnection(StorageClient.java:1629)
    at org.csource.fastdfs.StorageClient.do_upload_file(StorageClient.java:639)
    at org.csource.fastdfs.StorageClient.upload_file(StorageClient.java:162)
    at org.csource.fastdfs.StorageClient.upload_file(StorageClient.java:180)

很显著，是零碎无奈上传文件导致的问题，这个日志信息很重要，对问题的排查起到了至关重要的作用。

剖析起因

既然是上传文件呈现了问题，那我先试试能不能拜访以前上传的文件呢？通过验证，以前上传的文件是能够拜访的，再次验证了是上传文件的问题。

既然生产环境是应用的分布式文件系统，个别状况下是没哈问题的，上传文件呈现了问题，大概率的事件是服务器磁盘空间有余了。那我就来顺着这个思路排查下问题。

于是乎，我应用df -h 查看服务器的存储空间使用率，曾经达到 91% 了。

嗯，磁盘空间有可能是引起问题的起因。接下来，再来进一步确认下是否是磁盘空间造成的问题。

于是，我再关上 /etc/fdfs/ 目录下的 tracker.conf 的配置，看到预留的存储空间为 10%（注：这里的分布式文件系统应用的是 FastDFS）。

看到这里，能够确定就是磁盘空间有余造成的无奈上传文件的问题。

总体起因就是：服务器磁盘空间已应用 91%，而在分布式文件系统的配置中预留的磁盘空间为 10%，理论在上传文件的时候，零碎曾经检测到以后服务器残余的磁盘空间有余 10%，抛出异样，回绝上传文件。

到此，问题呈现的起因曾经确定了，接下来就是要解决问题了。

解决问题

首先，有两种形式能够解决这个问题，一种就是删除不须要的文件；另一种就是扩容磁盘空间。

删除不须要的文件

这种形式慎用，这里，我也简略的介绍下这种形式。我给小伙伴们提供了几种递归删除的形式。

递归删除.pyc 格局的文件。

find . -name '*.pyc' -exec rm -rf {} \;

打印以后文件夹下指定大小的文件

find . -name "*" -size 145800c -print

递归删除指定大小的文件(145800)

find . -name "*" -size 145800c -exec rm -rf {} \;

递归删除指定大小的文件，并打印进去

find . -name "*" -size 145800c -print -exec rm -rf {} \;

上面是对上述命令的一些简要阐明。

  • "." 示意从当前目录开始递归查找
  • “-name '*.exe' "依据名称来查找，要查找所有以.exe 结尾的文件夹或者文件
  • "-type f"查找的类型为文件
  • "-print" 输入查找的文件目录名
  • -size 145800c 指定文件的大小
  • -exec rm -rf {} \; 递归删除（后面查问进去的后果）

扩容磁盘空间

这里，冰河举荐应用这种形式，我修复生产环境的故障也是应用的这种形式。

通过查看服务器的磁盘空间发现，/data 目录下的空间足足有 5TB，呵呵，运维哥们为啥不把文件系统的数据存储目录指向 /data 目录呢。于是乎，我开始将文件系统的数据存储目录迁徙到 /data 目录下，整个过程如下所示。

留神：这里，我就简略的模仿将 /opt/fastdfs_storage_data 下的数据迁徙至 /data 下。

（1）拷贝文件，迁徙数据

cp -r /opt/fastdfs_storage_data  /data
cp -r  /opt/fastdfs_storage  /data
cp -r /opt/fastdfs_tracker /data

（2）批改门路

这里须要批改文件系统的 /etc/fdfs/storage.conf ,mod_fastdfs.conf ,client.conf,tracker.conf 文件。

  • /etc/fdfs/storage.conf
store_path0=/data/fastdfs_storage_data
base_path=/data/fastdfs_storage
  • /etc/fdfs/mod_fastdfs.conf
store_path0=/data/fastdfs_storage_data  (有两处)
base_path=/data/fastdfs_storage
  • /etc/fdfs/client.conf
base_path=/data/fastdfs_tracker
  • /etc/fdfs/tracker.conf
base_path=/data/fastdfs_tracker

从新建设 M00 至存储目录的符号连贯：
ln -s /data/fastdfs_storage_data/data /data/fastdfs_storage_data/data/M00

（3）杀掉过程, 重启存储服务 (追踪器和存储器)

顺次执行以下命令

  pkill -9 fdfs
  service fdfs_trackerd start
  service fdfs_storaged start

（4）批改文件的读取门路 nginx 配置

location ~/group1/M00{root /data/fastdfs_storage_data/data;}

（5）重启 nginx

cd /opt/nginx/sbin
./nginx -s reload

好了，问题搞定，经营能够失常上传图片和视频了。

好了，明天就到这儿吧，我是冰河，大家有啥问题能够在下方留言，也能够加我微信：sun_shine_lyz，我拉你进群，一起交换技术，一起进阶，一起牛逼~~

退出移动版