MooseFs-分布式文件系统系列（四）之简单聊聊MFS的日常维护

回顾

文件或目录的额外属性(noower,noattracache和noentrycache)，可以通过MFS提供的命令(mfsgeteattr,mfsseteattr,mfsdeleattr等)检查、设置和删除。其行为类似于mfsgettoal/mfssetgoal或者mfsgettrashtime/mfssettrashtime。

维护MFS

维护MFS，最重要的是维护元数据服务器，而元数据服务器最重要的目录就是为/usr/local/mfs/var/mfs（源码安装就在这里）。MFS数据的存储、修改和更新操作变化都会记录在这个目录的某个文件中、因此要保证这个目录的数据安全，就能保证整个MFS文件系统的安全性和可靠性。

/usr/local/mfs/var/mfs目录下的数据由两部分组成：一部分是元数据服务器的改变日志文件，文件名是changelog.*.mfs：另一个部分就是元数据文件metadata.mfs，运行mfsmaster时该文件就会被命名为metadata.mfs.back。只要保证了这两部书的数据安全，即使管理服务器操作破坏，也可以通过备份的元数据文件重新部署一套。

启动MFS集群

最安全的启动MFS集群(避免任何读写错误数据或者类似的问题)步骤如下：

启动mfsmaster进程。
启动所有的mfschunkserver进程
启动mfsmetalogger进程（如果有mfsmetalogger服务器的话）

当所有的数据存储服务器连接到MFS管理服务器后，任何数目的客户端都可以利用mfsmount去连接共享出来的文件系统（可以通过mfscgiserver提供的web界面查看或者mfsmaster日志）

停止MFS集群。

安全停止MFS集群，按照如下步骤进行操作：

在所有的客户端卸载MFS文件系统(利用umount命令即可卸载)。
利用mfschunkserver stop停止数据存储服务器进程。
利用mfsmetalogger stop停止元数据日志服务器进程。
利用mfsmaster stop停止管理服务器进程。

MFS存储服务器的维护

假如每个文件的goal(副本)都不小于2，并且没有under-goal文件（这些可以通过“mfsgetgoal -r”和mfsdirinfo命令来查看），那么一个数据存储服务器在任何时候都可以停止或重新启动。以后每当需要停止或者重新启动另一个数据存储服务器的时候，需要确定之前的数据存储服务器被链接，而且没有under-goal chunks。

MFS元数据备份

主要元数据文件metadata.mfs,在MFS的管理服务器master运行时会被命名为metadata.mfs.back。
元数据改变日志changelog.*.mfs，存储过去N小时内的文件改变（N数值是由BACK_LOGS参数设置的。参数设置在mfschunkserver.cfg配置文件中进行）

主要的元数据文件需要定期备份，备份的频率取决于多少个小时改变日志的存储。元数据改变日志应该时时的自动复制。从MFS1.6.5版本后，这两项任务都是由元数据日志服务器进程完成的。

MFS管理服务器的恢复

一旦服务器奔溃，需要最后一个元数据改变日志changelog和主要的元数据文件metadata.mfs。这个操作可以通过mfsmaster(在1.7版本以前用mfsmetarestore)命令来完成。命令如下所示：

[root@localhost mfs]# mfsmaster -a   #执行这个命令的时候，确保mfsmaster进程处于停止状态。

working directory: /usr/local/mfs/var/mfs   # 源码安装指定了/usr/local/mfs，那么默认是在这里。

关于恢复的时候指定元数据存储目录，我这也没发现用哪个命令去指定，在1.7版本以前的是mfsmetarestore -d来指定的。

从备份恢复MFS管理服务器。

为了从备份中恢复一个管理服务器，需要以下步骤进行：

安装一个新管理服务器。
利用通配的配置来配置新管理服务器（利用备份找回mfsmaster.cfg），配置文件需要备份的。
找回metadata.mfs.back文件，从备份服务器中找，也可以从元数据日志服务器中找（如果启动了元数据日志服务），然后把metadata.mfs.back文件放入mfs的数据目录下，源码安装的一般为${prefix}/var/mfs。
从管理服务器宕机之前任何运行元数据日志服务器上复制最后一个changelog.*.mfs文件，放入管理服务器的数据目录。
利用mfsmaster -a来合并元数据日志，自动恢复模式。

通过冗余实现失败防护的解决方案。

如题所示，其实就是一主一备的模式，当主的宕机后，备用机马上顶上去。

对于高可用的方案，我们可以采用keepalived或者heartbeat来做高可用。

对于元数据的一致性，我们还可以通过unison来做主备之间的双向元数据的同步，确保数据一致。