阿哥论坛

 找回密码
 立即注册

QQ登录

只需一步,快速开始

新浪微博账号登陆

只需一步,快速开始

搜索
查看: 390|回复: 0

moosefs-1.6.26报错信息一例及解决办法 -服务器架构

[复制链接]

2024

主题

1

好友

1万

积分

管理员

Rank: 9Rank: 9Rank: 9

优秀会员 助人为乐 辛勤工作 技术精英 多才多艺 优秀班竹 灌水天才 星球管理 宣传大使 灌水之王 财富勋章 版主勋章 动漫勋章 勤奋会员 论坛精英 PS高手 心 8 闪游皮肤 双鱼座 8★8➹ 志愿者 乖

发表于 2014-3-31 20:34:16 |显示全部楼层
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已经开始正常的运行,从而解决了日志中报错的信息。
    这个也强调,为了保证服务器的安全最好手工安全的结束掉服务器的进程,避免异常情况的发生。另外在异常情况出现之后需要全面的排查之前是否正常,异常前都进行了哪些操作,看看是否和异常情况的出现有关,找出问题的症结然后解决。
moosefs-1.6.26报错信息一例及解决办法 -服务器架构
摘自:http://blog.csdn.net/liuyunfengheda/article/details/8332066

该会员没有填写今日想说内容.
您需要登录后才可以回帖 登录 | 立即注册 新浪微博账号登陆

回顶部