这个是不是FastDFS Trunk使用中的一个无法避免的问题？

wangshuaiatwork

最近在学习和测试FastDFS中Trunk文件怎么使用，发现Trunk的binlog sync是由选举出的Trunk server来同步，不像Storage sync是由各个storage对等的发起。这样的话就会在切换Trunk Server的时候可能出现新老trunk server间的binlog不同步问题，导致会出现文件丢失，这个问题是不是没有办法避免？还请用过trunk的人帮忙回答。

场景重现：（一个tracker，两个Storage，步骤1,2上传文件写入的是同一个trunk文件）
1. storage1作为trunk server，断开storage2（模拟上传文件后storage1网络中断），上传文件A到Storage1，查看storage1上的trunk binlog和sync binlog正常，但此时storage2并没有这部分log。
2. 断开storage1，开启storage2，storage2作为新的trunk server，上传文件B到storage2，查看storage2上的trunk binlog和sync binlog也正常，但此时storage1和storage2各有对方没有的一部分log，其中trunk文件偏移量出现重叠。
3. 开启storage1，trunk的binlog由storage2向storage1同步，会覆盖storage1原有的binlog，sync的binlog在storage2和storage1之间互相同步。如果storage1的sync先发起同步，则会将文件A上传到storage2，文件上传会按照文件A的偏移量进行上传，这样会把storage2上同一个trunk文件相对应的偏移部分给覆盖，实际上就是文件B的内容。storage2再发起同步时，按照原有文件B的偏移量已经找不到文件B了，因为文件头已经被A覆盖了，所以文件B就在storage2上永远消失了，nginx也读不出来。如果是storage2先发起同步，则文件A在storage1上就会永远消失，集群里也没有这个文件了。

chang290

和楼主有同样地疑惑。

但是楼主的测试用例有问题，把storage-A停止后，启动storage-B，此时storage-B是无法启动的，因此取不到源，因此需要在一开始的时候把A、B都启动，然后停掉其中一台机器。
具体测试步骤如下：
1）启动两个tracker和两个storage，两个storage分别处于A、B两台机器
2）通过monitor工具查看，当前的trunk-server为A
3）通过客户端工具upload 1000个同样的文件（同样地文件利于下载文件后比较内容是否正确），并且将这些文件的fileid保存到一个文件列表之中，可以预见这1000个文件在storage-A、storage-B两台机器上都存在。
4）关闭storage-B进程，此时的trunk-server还是A
5）再次通过客户端工具upload 1000个同样地文件，将文件ID保存到文件列表之中，这些文件将只存在与storage-A之中，并且trunk-binlog无法同步出去。
6）关闭storage-A，然后启动storage-B，此时的trunk-server还是A，因此通过客户端工具upload会返回失败，因此没有trunk-server可以分配空间。
7）等待tracker却换trunk-server 从A到B（根据心跳时间，可能需要几分钟），可以通过查看两个tracker的logs/trunk_server_change.log文件，或者通过monitor工具查看B的if_trunk_server是否变成1，若已经变成则表示已经却换了trunk-server
8）通过客户端工具upload 1000个同样的文件，照样将文件ID保存到文件列表之中，这些文件将只存在与storage-B之中，并且trunk-binlog无法同步出去
9）启动storage-A，此时A、B都处于ACTIVE状态，他们之间就会互相进行同步文件，由于存储空间是独立分配的，因此他们之间同步时会存在文件覆盖的问题

接着等待A、B互相进行文件同步，需要一点时间：
验证：根据之前保存的文件FILEID列表，因此执行download操作，并且将下载到的数据与原始数据进行比较，就会发现有些文件download失败，有些数据不对。

chang290

恳请鱼大回答下这个问题？

shou55

我也测试遇到这个问题, 但准确的说是遇到2个问题, 与合并存储的trunk server有关:
(1)是2楼所提到的合并存储缺陷导致数据丢失或错误的问题
(2)是如果有多个组, 每个组有多个storage.  在配置store_lookup参数为2的情况下, 假设恰好是有最大空闲的那个组的trunk server挂掉了, 则会导致整个fastdfs都无法写入, 只能读取.  因为根据调度策略, tracker会把写入操作总是分配给最大空闲的那一组, 但最大空闲那一组的trunk server挂掉了会导致该组无法写入

李井新

关注一下这个问题

skymelai

没有答案吗？？？happy_fish是不是已经没有维护fastdfs了？

耗牛肉炊饼

这个问题应该如何解决呢

forest0517

我的办法是 <=16k的文件才trunk，否则还是按独立文件存。如此，既能节约inode，又能保证文件安全（重要文件都大于16k）
我的硬盘1t，inode size = 256字节，inode count=6000w，假设所有的文件都是20k，那么最终的大小 = 文件1200G + inode 15G，也就是说，如果存20k的小文件，inode数量不会是瓶颈。
另外，trunk file max size = 4M，减少被覆盖的几率。

抛砖引玉哈！

mm8m6m7m

FastDFS中Trunk文件使用 出现新数据和旧数据无法同步的现象。请问可以手动同步吗？可以的话能不能提供一下操作步骤。谢谢！

xocoder1989

这个问题大家有解决方案了吗？