數(shù)十T小文件如圖片，同步、備份等如何高效維護(hù)？

arkue

如題。

生產(chǎn)系統(tǒng)有臺(tái)圖片服務(wù)器，raid10、nginx，有數(shù)十T的小文件圖片居多，且因業(yè)務(wù)需要還在不斷更新文件和生成新文件。
照同樣硬軟件環(huán)境又搭建了一臺(tái)。用scp、du、rsync等維護(hù)時(shí)，執(zhí)行一次就需要十?dāng)?shù)個(gè)小時(shí)。
當(dāng)某臺(tái)服務(wù)器有文件變化，有沒有高效的處理辦法，能確保兩臺(tái)服務(wù)器手工同步、迅速統(tǒng)計(jì)這些小文件的數(shù)量和大小、部署差異或增量的自動(dòng)化腳本調(diào)度呢？

arkue

fanglq04

rsync + inotify

劍嘯易水寒

個(gè)人以為rsync應(yīng)該是抗不住的，呵呵，無論是推送還是拉取，都會(huì)需要考慮打開文件數(shù)和帶寬瓶頸，嚴(yán)重情況下直接可能導(dǎo)致站點(diǎn)訪問timeout，個(gè)人生產(chǎn)經(jīng)驗(yàn)如此。

個(gè)人公司服務(wù)器image master 和image slave均14塊2T scsi，組建raid60，ext4，解決方案是php+shell增量推送，master提供上傳和業(yè)務(wù)后臺(tái)，slave提供讀取操作，前端頁面會(huì)有延遲，但公司業(yè)務(wù)可以接受。

個(gè)人感覺這個(gè)和前期架構(gòu)設(shè)計(jì)有關(guān)，后期改動(dòng)動(dòng)作會(huì)比較大，，，架構(gòu)改動(dòng)期間，偶吃苦了~~~~呵呵

arkue

好滴 謝謝 研究下

geodge831012

這個(gè)大量的小文件是不是要考慮架構(gòu)問題了,比如合并成大文件,分布式之類,參考下fb的haystack的設(shè)計(jì)思路吧.

arkue

嗯 向fb學(xué)習(xí)

arkue

劍嘯易水寒 發(fā)表于 2012-06-11 23:00
個(gè)人以為rsync應(yīng)該是抗不住的，呵呵，無論是推送還是拉取，都會(huì)需要考慮打開文件數(shù)和帶寬瓶頸，嚴(yán)重情況下直 ...

加了inotifywait+rsync 把監(jiān)控的文件數(shù)開的足夠 內(nèi)存幾乎耗盡了 inotifywait也掛了

劍嘯易水寒

回復(fù) 8# arkue


    這個(gè)是必然的，樓主三思，避免蛋疼