FastDFS----recovery状态问题排查记录

 FastDFS问题排查记录

现象

今天有人反馈,客户端部分图标时而不能显示

问题定位

用jemter将图片地址进行简单测试后,发现偶尔有404 NOT FOUND的情况
在服务器上对八台nginx分别进行测试,发现144确实返回404
查看144 nginx的error日志,发现大量报错
[2016-08-22 15:51:25] ERROR - file: ../fastdfs-nginx-module/src//common.c, line: 870, file: /data/storage/data/01/3E/rBCJYle1KWyAfnfPAAAXYfqwv1U115.jpg not exist
[2016-08-22 15:51:25] ERROR - file: ../fastdfs-nginx-module/src//common.c, line: 870, file: /data/storage/data/01/42/rBCJYle20wmASFmaAAAQt5Rk5Lc743.jpg not exist
[2016-08-22 15:51:25] ERROR - file: ../fastdfs-nginx-module/src//common.c, line: 870, file: /data/storage/data/01/43/rBCJYle206mAcSQZAAANXK1DRHg664.jpg not exist
[2016-08-22 15:51:25] ERROR - file: ../fastdfs-nginx-module/src//common.c, line: 870, file: /data/storage/data/01/43/rBCJYle21DKAKYVHAAAH_vqF1FU344.jpg not exist
[2016-08-22 15:51:25] ERROR - file: ../fastdfs-nginx-module/src//common.c, line: 870, file: /data/storage/data/01/43/rBCJYle206qAY2JGAAAItZ1GE4c989.jpg not exist
至此,初步确定是fastDFS的该storage节点有问题

fastDFS分析

144 fdfs_storage 2

通过fdfs_monitor发现,该节点状态信息为recovery,上次同步时间为2016年3月8日…….(是有多久没发现这个问题了)
144上fdfs_storage进程没有,尝试启动失败。
查看144的fastDFS日志,如下
[2016-08-22 14:24:07] INFO - file: storage_disk_recovery.c, line: 750, disk recovery: begin recovery data path: /data/storage ...
[2016-08-22 14:24:07] INFO - file: storage_disk_recovery.c, line: 446, mark file "/data/storage/data/.recovery.mark", fetch_binlog_done=0, need to fetch binlog again
[2016-08-22 14:24:07] ERROR - file: tracker_proto.c, line: 48, server: 172.16.137.98:23000, response status 2 != 0
[2016-08-22 14:24:07] CRIT - file: storage_func.c, line: 1782, storage_check_and_make_data_dirs fail, program exit!
[2016-08-22 14:24:07] CRIT - exit abnormally!
大意为 开始恢复数据,binlog文件获取失败,重新获取,但是从同group的另一个storage(172.16.137.98:23000)获取binlog失败(response status 2 != 0),然后进程退出

143 fdfs_storage 1

既然是144从143上获取binlog失败,那就看看143出了什么问题

查看fdfs_monitor和143进程等信息未发现异常
想查看143的日志发现根本没有日志目录
lsof查看发现日志连同目录都被删了,所以不输出日志!
fdfs_trac 20986 root    1w   REG        8,2   235882  25952259 /data/tracker/logs/trackerd.log (deleted)
fdfs_trac 20986 root    2w   REG        8,2   235882  25952259 /data/tracker/logs/trackerd.log (deleted)
fdfs_trac 20986 root    3w   REG        8,2   235882  25952259 /data/tracker/logs/trackerd.log (deleted)
重新创建目录,然后计划重启143的storage
启动storage失败!启动命令执行后一直在控制台处于挂起状态!
fdfs_monitor中状态为offline!日志中显示准备开始恢复数据!
这又恢复的哪门子数据,斟酌后删除了/data/storage/data/下面的关于恢复数据的文件(.recovery.mark;.binlog.recovery )
重新启动成功
144 fdfs_storage 2

这下回到144上,再次尝试启动storage,成功了

[2016-08-22 15:11:20] INFO - file: storage_disk_recovery.c, line: 750, disk recovery: begin recovery data path: /data/storage ...
[2016-08-22 15:11:20] INFO - file: storage_disk_recovery.c, line: 446, mark file "/data/storage/data/.recovery.mark", fetch_binlog_done=0, need to fetch binlog again
[2016-08-22 15:11:20] INFO - file: storage_disk_recovery.c, line: 110, recovery binlog file size: 0
[2016-08-22 15:11:20] INFO - file: storage_disk_recovery.c, line: 750, disk recovery: begin recovery data path: /data/storage ...
[2016-08-22 15:11:20] INFO - file: storage_disk_recovery.c, line: 527, disk recovery: recovering files of data path: /data/storage ...
[2016-08-22 15:11:25] INFO - file: storage_disk_recovery.c, line: 725, disk recovery: recover files of data path: /data/storage done
[2016-08-22 15:11:25] INFO - file: storage_disk_recovery.c, line: 801, disk recovery: end of recovery data path: /data/storage
fdfs_monitor中144的状态终于变成active了 
不过文件同步时间还是3月8日,需要等待一段时间让新的同步完成。
原文地址:https://www.cnblogs.com/slim-liu/p/6064799.html