fastDFS同步问题讨论

一、文件同步延迟问题

前面也讲过fastDFS同组内storage server数据是同步的， Storage server中由专门的线程根据binlog进行文件同步。为了最大程度地避免相互影响以及出于系统简洁性考虑，Storage server对组内除自己以外的每台服务器都会启动一个线程来进行文件同步。文件同步采用增量同步方式，系统记录已同步的位置（binlog文件偏移量）到标识文件中。标识文件名格式：{dest storage IP}_{port}.mark，例如：192.168.1.14_23000.mark。Storage server采用binlog文件记录文件上传、删除等更新操作。binlog中只记录文件名，不记录文件内容。文件同步只在同组内的Storage server之间进行，采用push方式，即源头服务器同步给目标服务器。只有源头数据才需要同步，备份数据并不需要再次同步，否则就构成环路了。有个例外，就是新增加一台Storage server时，由已有的一台Storage server将已有的所有数据（包括源头数据和备份数据）同步给该新增服务器。客户端将一个文件上传到一台Storage server后，文件上传工作就结束了。由Storage server根据binlog中的上传记录将这个文件同步到同组的其他Storage server。这样的文件同步方式是异步方式，异步方式带来了文件同步延迟的问题。新上传文件后，在尚未被同步过去的Storage server上访问该文件，会出现找不到文件的现象

二、FastDFS对文件同步延迟问题的解决方案

需要说明的是，一个组包含的Storage server不是通过配置文件设定的，而是通过Tracker server获取到的。客户端和Storage server主动连接Tracker server。Storage server主动向Tracker server报告其状态信息，包括磁盘剩余空间、文件同步状况、文件上传下载次数等统计信息。Storage server会连接集群中所有的Tracker server，向他们报告自己的状态。Storage server启动一个单独的线程来完成对一台Tracker server的连接和定时报告。另外，每台storage server都会定时向tracker server报告它向同组的其他storage server同步到的文件时间戳。当tracker server收到一台storage server的文件同步报告后，它会依次找出该组内各个storage server被同步到的文件时间戳最小值，作为storage的一个属性记录到内存中。根据上述情况fastDFS提供下面简单解决方案：

、和文件更新一样，优先选择源Storage server下载文件即可。这可以在Tracker server的配置文件中设置，对应的参数名为download_server。

、选择Storage server的方法是轮流选择（round-robin）。当Client询问Tracker server有哪些Storage server可以下载指定文件时，Tracker server返回满足如下四个条件之一的Storage server：

a、该文件上传到的源Storage server，文件直接上传到该服务器上的；

b、文件创建时间戳 < Storage server被同步到的文件时间戳，这意味着当前文件已经被同步过来了；

分钟）；

天，表示文件同步在一天内肯定可以完成。

三、停止fastDFS服务

直接kill即可让server进程正常退出，可以使用killall命令，例如：
killall fdfs_trackerd
killall fdfs_storaged
也可以使用FastDFS自带的stop.sh脚本，如：
/usr/local/bin/stop.sh  /usr/local/bin/fdfs_storaged /etc/fdfs/storage.conf
stop.sh只会停止命令行（包括参数）完全相同的进程。
但需要注意的是千万不要使用-9参数强杀，否则可能会导致binlog数据丢失的问题。

四、fastDFS数据清空重整
停止storage server和tracker server，删除base_path下的data子目录即可。