开源组件Hadoop之目录满导致的hdfs journalnode问题处理

乍一看红的不少挺吓人，但仔细查看会发现，其实所有的报错都指向同一处，node11节点。尝试登录无果，ping对应IP无反应。

这种情况下，基本断定node11服务器异常宕掉了。本着老鸟的敏觉性，检查hdfs可用性及数据块，不过也不用过分担心，毕竟咱是大数据平台，挂一台服务器不影响整体可用性。检查确认所有hdfs数据块显示均为健康状态，也意味着后台数据并未受到任何影响，管理节点也已从node11节点成功漂移。

虽说只是测试环境，但毕竟是机器挂掉了，本着闭环服务思维，还是需要快速恢复的。说时迟，那时快，那时不如这时快，迅速掏出手机联系主机侧重启服务器。服务器起来后迅速登录，习惯性df一把，发现根目录使用率100%。检查使用详情，发现某个测试应用程序跑飞了，又没人看（测试环境都是这命啊），结果打了几百G的日志。二话不说直接联系应用侧询问是否可以直接清理，得到确认后，予以清理。

问题定位解决，虽然是大数据平台，但是宕掉的机器服务还是需要恢复的，不然禁不起再垮一轮。恢复node11各个服务后，平台恢复正常。但只是眨了一下眼，journalnode的绿色一闪而过，过后还是红色依旧。

快速登录服务器检查journalnode日志，发现node11的journalnode服务有问题，一直在报错检测到valid length，进入journalnode的数据目录，查看journalnode的edits时间，发现最新的并不是当前时间，与另外两个journalnode时间不一致，且一直不刷新。

综前分析，此前的根目录满导致node11节点最新的edits文件已经无法正常写入，进而导致journalnode服务重启，journalnode服务重启后无法与另外的journalnode正常同步。

好在我们的journalnode有少数服从多数机制，停止有问题的node11节点的journalnode服务，直接mv掉node11节点的所有edits文件（注意只移走edits开头文件，VERSION等其他信息需要保留，这可是身份信息，处理不当会导致同步edits失败），然后再次启动journalnode服务，发现node11已经可以与其他两个节点正常同步了。

本次的故障解决完成，后续会继续给大家带来关于大数据平台用到的相关组件的运维分享，敬请期待。