問(wèn)一下機(jī)房容災(zāi)的FastDFS系統(tǒng)部署

wangshuaiatwork

版主，我們現(xiàn)在考慮做FastDFS的異地IDC容災(zāi)，使用的是trunk文件，目前有兩種方案，請(qǐng)幫忙回答一下下面的問(wèn)題。
1. 一種是寫(xiě)程序定期同步新增的trunk文件和dat文件，但如果trunk文件中產(chǎn)生了小文件的刪除和新增，則需要重傳trunk塊。問(wèn)下目前有沒(méi)有配置可以使得舊trunk塊中的小文件被刪除后，新的文件只在新的trunk中存，不在舊的中存？
2. 另一種是把異地的storage加到同一個(gè)組里，依靠FastDFS自身的binlong進(jìn)行同步。為了使得異地storage完全不參與上傳，是否可以利用upload_priority參數(shù)實(shí)現(xiàn)？另外，如果想實(shí)現(xiàn)主機(jī)房故障以后的failover，是故障后在異地機(jī)房新起一個(gè)tracker好還是初期部署的時(shí)候就在異地部署一個(gè)同等的tracker好？

ruochen

期待詳解

容災(zāi)機(jī)房異地同步storage完全后也不參與寫(xiě)，只做同步
做機(jī)房遷移和容災(zāi)機(jī)房的時(shí)候這個(gè)很有用

harchiko

同期待詳解，估計(jì)這個(gè)應(yīng)該直接使用第三方吧。FASTDFS好像沒(méi)做類似的考慮？

wangshuaiatwork

1. 根據(jù)測(cè)試，發(fā)現(xiàn)trunk這種方式異地容災(zāi)恢復(fù)時(shí)由于肯定會(huì)出現(xiàn)trunk server漂移，所以可能會(huì)出現(xiàn)文件互相覆蓋丟失的現(xiàn)象，使用普通的小文件理論上不會(huì)出現(xiàn)文件丟失的情況。
2. 目前的fastdfs配置還無(wú)法提供同等優(yōu)先級(jí)間的storage輪詢上傳的功能，所以如果想要實(shí)現(xiàn)在一個(gè)組里只在主環(huán)境的storage上傳、下載，備環(huán)境的storage只同步，目前還無(wú)法實(shí)現(xiàn)，期待余大可以把這個(gè)點(diǎn)加到下個(gè)release。

hermann.zhen

最近我想用異地同組的storage server來(lái)做fastdfs，想實(shí)現(xiàn)一個(gè)類似CDN加速的效果，想法是上傳的用戶通過(guò)tracker選擇一個(gè)就近的storage server上傳文件，等待storage server之間進(jìn)行復(fù)制，異地的用戶訪問(wèn)文件時(shí)通過(guò)tracker來(lái)返回一個(gè)最近storage server給用戶訪問(wèn)。
不知道這樣是否可行有沒(méi)有人這樣做過(guò)，主要是不是很了解tracker是通過(guò)怎么樣的規(guī)則或算法來(lái)選擇storage server。

hermann.zhen

試了一下，fastdfs是不是不能在防火墻后面去做？

ruochen

頂一下