背景：
项目使用fastdfs作为分布式文件系统，前天有客户反馈说某一节点下载文件失败。服务器登陆不上，运维后面反馈说硬盘坏了，只能恢复到19年12月份的数据。
在不影响现在业务的前提下，利用现有业务逻辑踢除了此节点的访问。那现在我们开始进行数据修复吧。
首先了解一下binlog的相关知识：
截图里的最前面是时间戳，记录操作的时间
中间的是操作类型:
C表示源创建、c表示副本创建
A表示源追加、a表示副本追加
D表示源删除、d表示副本删除
T表示源Truncate、t表示副本Truncate
最后是文件存储的相对路径，文件名是随机生成的，所以看不出具体是啥文件。
通过相关了解，同组内非源操作不需要同步，就是每个节点的不是源文件的（代表C）是不会同步到其它机器上。因为文件都不是固定从一个节点上上传的，所以原先上传到这一台硬盘故障上的文件就无法同步了，那怎么办呢？
进一步了解，新增节点时会从其中一个节点同步所有数据。
第一步删除故障节点：
fdfs_monitor /etc/fdfs/storage.conf delete groupname 192.168.1.43
根据自己的实现情况修改并执行
fdfs_monitor /etc/fdfs/storage.conf 确定节点已经删除
第二步删除相关此节点相关信息：
其它节点的只需到对应sync目录下把192.168.1.43.mark.2020041421291 删除，后面带的时间各不同，注意查看。
至于sync目录在哪，要看实际安装的目录在那，我的在/data/fastdfs/storage/groupname/data/sync
硬盘故障节点的信息删除就有些不一样，首先把/data/fastdfs/storage/groupname/data/storage_stat.dat 下的文件删除，再清空/data/fastdfs/storage/groupname/data/sync即可
第三步重启服务：
原先的trackerd服务重启，然后其它节点重启storaged服务，再 fdfs_monitor /etc/fdfs/storage.conf 确定故障节点信息已经不存在了。最后重启硬盘故障节点的storaged服务，然后就等着同步的完成。已经存在的文件不会重新同步过来，只会作记录。