這個(gè)是不是FastDFS Trunk使用中的一個(gè)無法避免的問題？

wangshuaiatwork

最近在學(xué)習(xí)和測(cè)試FastDFS中Trunk文件怎么使用，發(fā)現(xiàn)Trunk的binlog sync是由選舉出的Trunk server來同步，不像Storage sync是由各個(gè)storage對(duì)等的發(fā)起。這樣的話就會(huì)在切換Trunk Server的時(shí)候可能出現(xiàn)新老trunk server間的binlog不同步問題，導(dǎo)致會(huì)出現(xiàn)文件丟失，這個(gè)問題是不是沒有辦法避免？還請(qǐng)用過trunk的人幫忙回答。

場(chǎng)景重現(xiàn)：（一個(gè)tracker，兩個(gè)Storage，步驟1,2上傳文件寫入的是同一個(gè)trunk文件）
1. storage1作為trunk server，斷開storage2（模擬上傳文件后storage1網(wǎng)絡(luò)中斷），上傳文件A到Storage1，查看storage1上的trunk binlog和sync binlog正常，但此時(shí)storage2并沒有這部分log。
2. 斷開storage1，開啟storage2，storage2作為新的trunk server，上傳文件B到storage2，查看storage2上的trunk binlog和sync binlog也正常，但此時(shí)storage1和storage2各有對(duì)方?jīng)]有的一部分log，其中trunk文件偏移量出現(xiàn)重疊。
3. 開啟storage1，trunk的binlog由storage2向storage1同步，會(huì)覆蓋storage1原有的binlog，sync的binlog在storage2和storage1之間互相同步。如果storage1的sync先發(fā)起同步，則會(huì)將文件A上傳到storage2，文件上傳會(huì)按照文件A的偏移量進(jìn)行上傳，這樣會(huì)把storage2上同一個(gè)trunk文件相對(duì)應(yīng)的偏移部分給覆蓋，實(shí)際上就是文件B的內(nèi)容。storage2再發(fā)起同步時(shí)，按照原有文件B的偏移量已經(jīng)找不到文件B了，因?yàn)槲募�頭已經(jīng)被A覆蓋了，所以文件B就在storage2上永遠(yuǎn)消失了，nginx也讀不出來。如果是storage2先發(fā)起同步，則文件A在storage1上就會(huì)永遠(yuǎn)消失，集群里也沒有這個(gè)文件了。

chang290

和樓主有同樣地疑惑。

但是樓主的測(cè)試用例有問題，把storage-A停止后，啟動(dòng)storage-B，此時(shí)storage-B是無法啟動(dòng)的，因此取不到源，因此需要在一開始的時(shí)候把A、B都啟動(dòng)，然后停掉其中一臺(tái)機(jī)器。
具體測(cè)試步驟如下：
1）啟動(dòng)兩個(gè)tracker和兩個(gè)storage，兩個(gè)storage分別處于A、B兩臺(tái)機(jī)器
2）通過monitor工具查看，當(dāng)前的trunk-server為A
3）通過客戶端工具upload 1000個(gè)同樣的文件（同樣地文件利于下載文件后比較內(nèi)容是否正確），并且將這些文件的fileid保存到一個(gè)文件列表之中，可以預(yù)見這1000個(gè)文件在storage-A、storage-B兩臺(tái)機(jī)器上都存在。
4）關(guān)閉storage-B進(jìn)程，此時(shí)的trunk-server還是A
5）再次通過客戶端工具upload 1000個(gè)同樣地文件，將文件ID保存到文件列表之中，這些文件將只存在與storage-A之中，并且trunk-binlog無法同步出去。
6）關(guān)閉storage-A，然后啟動(dòng)storage-B，此時(shí)的trunk-server還是A，因此通過客戶端工具upload會(huì)返回失敗，因此沒有trunk-server可以分配空間。
7）等待tracker卻換trunk-server 從A到B（根據(jù)心跳時(shí)間，可能需要幾分鐘），可以通過查看兩個(gè)tracker的logs/trunk_server_change.log文件，或者通過monitor工具查看B的if_trunk_server是否變成1，若已經(jīng)變成則表示已經(jīng)卻換了trunk-server
8）通過客戶端工具upload 1000個(gè)同樣的文件，照樣將文件ID保存到文件列表之中，這些文件將只存在與storage-B之中，并且trunk-binlog無法同步出去
9）啟動(dòng)storage-A，此時(shí)A、B都處于ACTIVE狀態(tài)，他們之間就會(huì)互相進(jìn)行同步文件，由于存儲(chǔ)空間是獨(dú)立分配的，因此他們之間同步時(shí)會(huì)存在文件覆蓋的問題

接著等待A、B互相進(jìn)行文件同步，需要一點(diǎn)時(shí)間：
驗(yàn)證：根據(jù)之前保存的文件FILEID列表，因此執(zhí)行download操作，并且將下載到的數(shù)據(jù)與原始數(shù)據(jù)進(jìn)行比較，就會(huì)發(fā)現(xiàn)有些文件download失敗，有些數(shù)據(jù)不對(duì)。

chang290

懇請(qǐng)魚大回答下這個(gè)問題？

shou55

我也測(cè)試遇到這個(gè)問題, 但準(zhǔn)確的說是遇到2個(gè)問題, 與合并存儲(chǔ)的trunk server有關(guān):
(1)是2樓所提到的合并存儲(chǔ)缺陷導(dǎo)致數(shù)據(jù)丟失或錯(cuò)誤的問題
(2)是如果有多個(gè)組, 每個(gè)組有多個(gè)storage.  在配置store_lookup參數(shù)為2的情況下, 假設(shè)恰好是有最大空閑的那個(gè)組的trunk server掛掉了, 則會(huì)導(dǎo)致整個(gè)fastdfs都無法寫入, 只能讀取.  因?yàn)楦鶕?jù)調(diào)度策略, tracker會(huì)把寫入操作總是分配給最大空閑的那一組, 但最大空閑那一組的trunk server掛掉了會(huì)導(dǎo)致該組無法寫入

李井新

關(guān)注一下這個(gè)問題

skymelai

沒有答案嗎？？？happy_fish是不是已經(jīng)沒有維護(hù)fastdfs了？

耗牛肉炊餅

這個(gè)問題應(yīng)該如何解決呢

forest0517

我的辦法是 <=16k的文件才trunk，否則還是按獨(dú)立文件存。如此，既能節(jié)約inode，又能保證文件安全（重要文件都大于16k）
我的硬盤1t，inode size = 256字節(jié)，inode count=6000w，假設(shè)所有的文件都是20k，那么最終的大小 = 文件1200G + inode 15G，也就是說，如果存20k的小文件，inode數(shù)量不會(huì)是瓶頸。
另外，trunk file max size = 4M，減少被覆蓋的幾率。

拋磚引玉哈！

mm8m6m7m

FastDFS中Trunk文件使用 出現(xiàn)新數(shù)據(jù)和舊數(shù)據(jù)無法同步的現(xiàn)象。請(qǐng)問可以手動(dòng)同步嗎？可以的話能不能提供一下操作步驟。謝謝！

xocoder1989

這個(gè)問題大家有解決方案了嗎？