mfs使用指引
客户端工具集
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，但丢失的数据暂无法确定
