moosefs-1.6.26报错信息一例及解决办法

   mfs-1.6.26安装之后一直运行很好,但是在一次服务器重启之后/var/log/message中出现如下的错误:
Dec 19 12:00:00 ngmaster mfsmaster[10904]: previous metadata save process hasn't finished yet - do not start another one
Dec 19 13:00:00 ngmaster mfsmaster[10904]: previous metadata save process hasn't finished yet - do not start another one
Dec 19 14:00:00 ngmaster mfsmaster[10904]: previous metadata save process hasn't finished yet - do not start another one
    为此对原因进行分析,发现都是整点的出现的,从报错的信息来看是上一次的元数据归档并未完成,从而在整点时再启用归档时就出现无法启动的情况。因此从两方面进行查看:
    1、查看mfs master的元数据,发现元数据一直停留在服务器启动的时间,而changelog.0.mfs已经达到80M,而之前类似的changelog.1.mfs都是一小时归档一次到metadata.mfs.back中的,为什么这次会出现这样的情况呢?仔细对比发现在更换过mfs-1.6.26之后还是每小时都归档一次的,异常情况是从服务器重启之后出现的。
    2、查看mfs metalogger的服务器,发现同步过来的文件和mfs master上的数据是一致的,也就排除了是因为mfs metalogger同步数据异常导致的原因。
    3、再次将目光定位到mfs master上,发现了之前可能忽略的metadata.mfs.back.tmp文件,这个文件的大小只是metadata.mfs.back的一半大小,这就是有可能另外一名同事并没有正常关闭mfs master,有可能是在mfs master的元数据进行归档期间关闭的,也就导致了这种异常的情况。
    4、为了印证想法,查看了同事的操作记录的历史命令和操作的时间,正是在这整点的时间进行的kill的操作,也就导致的metadata.mfs.back.tmp在并为归档完成的情况杀掉了mfs master的进程。
    5、手工删掉metadata.mfs.back.tmp,然后整点查看metadata.mfs.back和changelog.0.mfs已经开始正常的运行,从而解决了日志中报错的信息。
    这个也强调,为了保证服务器的安全最好手工安全的结束掉服务器的进程,避免异常情况的发生。另外在异常情况出现之后需要全面的排查之前是否正常,异常前都进行了哪些操作,看看是否和异常情况的出现有关,找出问题的症结然后解决。

你可能感兴趣的:(MFS)