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提供下面简单解决方案:
1、和文件更新一样,优先选择源Storage server下载文件即可。这可以在Tracker server的配置文件中设置,对应的参数名为download_server。
2、选择Storage server的方法是轮流选择(round-robin)。当Client询问Tracker server有哪些Storage server可以下载指定文件时,Tracker server返回满足如下四个条件之一的Storage server:
a、该文件上传到的源Storage server,文件直接上传到该服务器上的;
b、文件创建时间戳 < Storage server被同步到的文件时间戳,这意味着当前文件已经被同步过来了;
c、文件创建时间戳=Storage server被同步到的文件时间戳,且(当前时间—文件创建时间戳) > 一个文件同步完成需要的最大时间(如5分钟);
d、(当前时间—文件创建时间戳) > 文件同步延迟阈值,比如我们把阈值设置为1天,表示文件同步在一天内肯定可以完成。
三、停止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子目录即可。