手工安装Cloudera Manager托管Hadoop记录

CM Install

Posted by biaobean on August 10, 2016

14:00

开始停止集群服务

15:00

发现NN和SNN报告数据不同。怎么办?重启SNN呗~ :) 记录集群状态 ### 22:00

结果了N个小时个鏖战,发现了N个CM的小bug,CM界面说的edit.dir不设置就会使用name.dir,经测试不行,如果不设置将报错,且报的错非常诡异,NN报fsmsg目录lock失败,原因是已经被自己lock了!

原来把namedir设置错有各种不同的报错啊,

  • 如果后面以/结尾,报文件找不到
  • 如果是目录错误,但存在且有权限,不会爆fsimage找不到,而是报edits stream为空

HA不能直接设置啊!只能拆了再上啊~如何将HA拆除没有官方的方式,强行拆除时发现edit文件丢失、NameNode状态不能恢复。人肉手工从JournalNode修复editlog文件到NameNode,成功将NN拉起来,验证数据块没问题。

开始通过CM添加HDFS服务并启动HA。

CM太傻逼了,启动HA任何一点小错误一言不合就失败

  • 目录不对,不做
  • SNN、JN目录不空,不做
  • 内存分配太大,不做

关键是怎么样才是丫认可的初始状态没有任何的说明文档,只能在一一的试,CM心,海底针啊~

而且一旦失败退出,CM还是会认为HA已经启动,但内部状态完全不对且不能手工修复,所以每次只能把HDFS服务删除了重新添加、一个个的再设置参数然后再试啊~好吧,阿Q一下,生命也许就是用来浪费的~

终于把HDFS 配置完成了

23:00

HDFS退出安全模式,所有block和文件数目及状态正常。

23:20

安装简单YARN服务完成

24:00

安装配置Hive完成,

24:30

配置YARN完成。要说YARN的优化需要定制化毛毛多的参数,因此配置起来及其花费时间,也很容易出错。

1:00

CM管理进程状态修复,所有服务启动且监测正常,ETL任务检验执行正常,准备发喜报。

1:10

噩耗来临,发现HDFS上50%左右的数据丢失!HDFS使用空间和文件个数极具减少!人生立刻跌入到了最低点!

1:30

发现从23:20左右NameNode开始主动大量删除数据,且不进入垃圾箱,丢失的数据已经无法找回。 HDFS已经进入稳定,不再删除数据,数据只剩下了20%不到。

2:00

终于查出丢失的是什么数据了,原来(作者在此故意隐去一万字),难怪在以前的路演中没有发现这个问题。

教训

  1. CM的设置中,如果参数类型为目录,不能以/结尾
  2. 下次做大操作前最好先合并image
  3. 再完备的测试也抵不过现场的复杂。小孩子一定要在家长陪同下实施Hadoop。