客戶端工具集 ~~~ mfsgetgoal #設定副本數 mfssetgoal #獲取副本數 mfscopygoal # mfsgetsclass mfssetsclass mfscopysclass mfsxchgsclass mfslistsclass mfsgettrashtime #設定回收站時間 mfssettrashtime #設定回收站時間 mfscopytrashtime mfsgeteattr #設置權限 mfsseteattr #獲取權限 mfsdeleattr mfscopyeattr mfsgetquota mfssetquota mfsdelquota mfscopyquota mfscheckfile #檢查文件 mfsfileinfo #文件信息 mfsappendchunks mfsdirinfo #目錄信息 mfsfilerepair #文件修復 mfsmakesnapshot #快照 mfsfilepaths mfschkarchive mfssetarchive mfsclrarchive mfsscadmin deprecated tools: // 遞歸設置 mfsrgetgoal = mfsgetgoal -r mfsrsetgoal = mfssetgoal -r mfsrgettrashtime = mfsgettreshtime -r mfsrsettrashtime = mfssettreshtime -r ~~~ mfsmaster運行目錄下的文件介紹 ~~~ metadata.mfs.back #MFS元數據信息，延遲將內存數據寫入文件，默認頻率1h，默認1d同步一次此文件到metalogger server changelog.*.mfs #文件操作日志記錄，實時記錄、同步到metalogger server sessions.mfs #客戶操作狀態記錄 stats.mfs #？ ~~~ mfsmaster的權限管理（類似于nfs的exports文件） ~~~ vi /etc/mfs/mfsexports.cfg #客戶端IP 允許掛載的目錄 客戶端擁有的權限 192.168.1.5 / rw,alldirs,maproot=0 # /標識MFS的根(讀寫的方式共享，允許掛載任何指定的子目錄) 192.168.0.0/24 . rw # .標識MFSMETA 文件系統 #客戶端 #目錄部分需要注意兩點 #權限部分 #*　所有客戶機 / 標識MooseFS 根 ro　只讀模式共享 #f.f.f.f 單個主機 . 表示MFSMETA 文件系統 rw　讀寫的方式共享 #f.f.f.f/p 某個子網段 alldirs 允許掛載任何指定的子目錄 #f.f.f.f-d.d.d.d 某兩個ip段區間 maproot 映射為root，還是指定的用戶 password 指定客戶端密碼 ~~~ 客戶端掛載文件系統（使用命令：mfsmount） ~~~ mfsmount可用參數 -H #接管理服務器IP -P #接管理服務器端口 -S #指出被掛接mfs 目錄的子目錄，默認是/目錄，就是掛載整個mfs 目錄 -m #這樣可以掛載一個輔助的文件系統mfsmeta，輔助文件系統可以在如下兩個方面恢復丟失的數據 ~~~ 設定數據副本數量 ~~~ #設定數據副本數量 #在客戶掛載好的目錄下創建，兩個用于測試的目錄 mkdir /data/test{1,2} #設置存放文件的份數 mfssetgoal 1 /data/test1 #注意：對于已經存在的文件不會改變其副本數，只對后續新寫入的文件副本數生效 mfssetgoal -r 2 /data/test2 #此時所有已存在的文件及子目錄副本數為2，并且新寫入的文件和子目錄的副本數也為2 #注意若是空文件，那么在后端chunk上是不會創建文件的，只會出現在元數據中 #注意：文件及目錄所保留的真實副本數是依據數據存儲服務器的數量，如果數據存儲服服務器只有兩臺，但卻為文件及目錄設定了3個副本的話，最后的真實副本數為2 #復制文件到對應的目錄 cp /etc/hosts /data/test1 cp /etc/hosts /data/test2 #驗證1 [root@client68 ~]# mfsfileinfo /data/test1/hosts /data/test1/hosts: chunk 0: 0000000000000029_00000001 / (id:41 ver:1) copy 1: 192.168.1.65:9422 (status:VALID) [root@client68 ~]# mfsfileinfo /data/test2/hosts /data/test2/hosts: chunk 0: 000000000000002A_00000001 / (id:42 ver:1) copy 1: 192.168.1.66:9422 (status:VALID) copy 2: 192.168.1.67:9422 (status:VALID) #驗證2 [root@client68 ~]# mfsgetgoal /data/ /data/: 2 [root@client68 ~]# mfsgetgoal /data/test1 /data/test1: 1 [root@client68 ~]# mfsgetgoal /data/test2 /data/test2: 2 ~~~ 設定垃圾回收站，回收時間（使用命令：mfssettrashtime　，可以使用-r 參數遞歸） ~~~ #一個被刪除文件能夠存放在一個“ 垃圾箱”的時間就是一個隔離時間， 這個時間可以用 mfsgettrashtime 命令來驗證，也可以使用`mfssettrashtime 命令來設置 #設置刪除文件最長保留時間，單位為秒（0：表示立即徹底刪除，1小時：3600；1天：86400；一周：604800；1月：2592000） mfssettrashtime 64800 /data/test1 mfsgettrashtime /data/test1 #獲取刪除文件最長保留時間（驗證） ~~~ 快照snapshot（使用命令：mfsmakesnapshot） ~~~ 快照snapshot（使用命令：mfsmakesnapshot） #可以給任何一個文件或目錄樹做快照，前提是必須是在mfs體系里的 #語法：mfsmakesnapshot src dst mfsmakesnapshot /data/test2/hosts /data/ #是在一次執行中整合了一個或是一組文件的拷貝，而且任何修改這些文件的源文件都不會影響到源文件的快照， 就是說任何對源文件的操作,例如寫入源文件，將不會修改副本 a：對一個文件做snapshot后，查看兩個文件的塊，是同一個塊。把原文件刪除，原文件刪除后（回收站中最初可以看到，但一段時間后，回收站中就徹底刪除了），snapshot文件仍然存在，并且可以訪問。使用mfsfileinfo查看，發現仍然是原來的塊。 b：對一個文件做snapshot后，查看兩個文件的塊，是同一個塊。把原文件修改后，發現原文件使用的塊名變了，即使用的是一個新塊。而snapshot文件仍然使用原來的塊。 ~~~ 如何在回收站（trash）中將刪除的數據恢復 ~~~ 如何在回收站（trash）中將刪除的數據恢復 #思路：在垃圾箱有效時限內，掛載mfsmeta文件系統，定位到被刪除的文件，將其移動到所在目錄下的　undel　目錄即可 1：確保垃圾箱的回收時間稍大一點，方便做實驗 [root@client68 undel]# mfsgettrashtime /data/test1/ /data/test1/: 86400 2：創建文件，輸入內容，然后保存，并刪除 touch /data/test1/hello echo "我們是共產主義接班人"　>> /data/test1/hello rm /data/test1/hello 3：先掛載mfsmeta文件系統 mount -m -H 192.168.1.61 /tmp/ceshi 4：定位文件（根據文件名） [root@client68 ~]# find /tmp/ceshi/trash/ -name "*hello*" /tmp/ceshi/trash/00F/0000000F|test1|hello 5：查看定位到文件內容（注意：一定要用單引號） [root@client68 ~]# cat '/tmp/ceshi/trash/00F/0000000F|test1|hello' test1/hello 6：恢復文件成功（移動這個文件到文件所在目錄下的undel下面，將會使原始的文件恢復到正確的MFS文件系統原來的路徑下） [root@client68 ~]# cd /tmp/ceshi/trash/00F [root@client68 00F]# ls 0000000F|test1|hello undel [root@client68 00F]# pwd /tmp/ceshi/trash/00F [root@client68 00F]# mv 0000000F\|test1\|hello ./undel/ [root@client68 00F]# ls /data/test1/ hello [root@client68 00F]# cat /data/test1/hello 我們是共產主義接班人 #注意：在恢復文件的時候，原來被刪文件下面的目錄下，不能有同名文件，不然恢復不成功 ~~~ MFS元數據備份 ~~~ 通常元數據有兩部分的數據： #主要元數據文件metadata.mfs，當mfsmaster 運行的時候會被命名為metadata.mfs.back 元數據改變日志changelog.*.mfs，存儲了過去的N 小時的文件改變（N 的數值是由BACK_LOGS參數設置的，參數的設置在mfschunkserver.cfg 配置文件中）。 #主要的元數據文件需要定期備份，備份的頻率取決于取決于多少小時changelogs 儲存。元數據changelogs 實時的自動復制。1.6版本中這個工作都由metalogger完成。 ~~~ MFSMaster的恢復 ~~~ #需要最后一個元數據日志changelog 并入主要的metadata 中。這個操作時通過 mfsmetarestore 工具做的 #先修復（幾次測試發現：如果mfsmetarestore -a無法修復，則使用metalogger也無法修復） mfsmetarestore -a #如果master 數據被存儲在MooseFS 編譯指定地點外的路徑，則要利用-d 參數指定使用，如： mfsmetarestore -a -d /opt/mfsmaster #再啟動(才能成功) #強制使用metadata.mfs.back創建metadata.mfs，可以啟動master，但應該會丟失1小時的數據。 #明確表示會丟失故障點到上一個整點之間的數據。和之前我猜測的一致。因為對mfs的操作日志都記錄到changelog.0.mfs里面。changelog.0.mfs每小時合并一次到metadata.mfs中，如果突然斷電，則changelog.0.mfs里面的信息就沒有合并到metadata中，強制使用metadata.mfs.back創建metadata.mfs，就會導致丟失changelog.0.mfs里的數據。 ~~~ 從MetaLogger中恢復Master ~~~ #在MetaLogger上，使用mfsmetarestore -a 命令,合并changelogs，然后將其角色提升為mfsmaster. #強制使用metadata.mfs.back創建metadata.mfs，可以啟動master，但丟失的數據暫無法確定 ~~~