cloudera manager的重建

cm的重建

难题
cdh的cm节点完全挂掉之后，根据：

https://www.bbsmax.com/A/nAJv0kGdrk/

https://community.cloudera.com/t5/Cloudera-Manager-Installation/cloudera-manager-database-lost/td-p/31989

的说明，本来打算进行重建式的恢复。

但此方法隐藏的风险巨大，包括已经运行了很久的集群配置，有不少的变化，很难保证完全还原。

另外，我们的cdh这次要修复的情况，和网上的情况有不同：

网上是cm加scm数据库都挂了，可能还涉及hdfs主节点的修复；

我们是cm挂了，moniter服务挂了，数据库完好，hdfs等服务还在正常运行。

根据官方文档：https://www.cloudera.com/documentation/enterprise/5-6-x/topics/cm_ag_restore_server.html

原本以为必须要原样的/var/lib/cloudera-scm-server目录下的内容，才能恢复。

在hd-cm启动时，我们拿到了此内容，并在其它机器上试过，启动不了。加深了对“不可恢复”的理解。

但其实，问题并非如此复杂。

观察
利用test[1-5]的机器，搭建了测试用小集群。在反复实验的过程中，发现了如下情况：

1 /var/lib/cloudera-scm-server 目录下的内容，主要是temp search commands，这些内容，即使清空，也能由scm数据库恢复。

2 monitor服务本身，是一种agent进程，和/var/lib/cloudera-scm-server 目录内容无关。

3 monitor服务，可以经由cm管理界面，重建。

4 原集群scm表前后，并没有本质的变化（原以为是大变，导致集群暂停）

对cdh的搭建方法，也进行了一些调查。在之前试的过程中，安装的方式有一些缺点。

cdh的安装
http://www.jianshu.com/p/331d36558ee2

http://blog.csdn.net/jjfnjit/article/details/49099015

cdh整体的示意图如下，服务和数据是分离的，这也是能够重建cm的本质原因。

过程如下：

cm机器在10.96.30.173

关闭iptables
$ service iptables stop
$ chkconfig iptables off

关闭SELINUX
$ vim /etc/selinux/config
$ SELINUX=disabled

依赖的软件服务（在要安装CM的机器上进行，需要上网）
#yum -y install postgresql-server
yum -y install httpd
yum -y install perl
yum -y install bind-utils
yum -y install cyrus-sasl-gssapi
yum -y install nc
yum -y install openssh-clients

主要是为了装httpd服务

准备cm和cdh的包
http://archive.cloudera.com/cm5/redhat/6/x86_64/cm/5.3.2/
=> /var/www/html/cloudera-manager/5.3.2

http://archive-primary.cloudera.com/cdh5/parcels/5.3.2/

=> /var/www/html/parcels/5.3.2

（parcels的sha1文件改为sha文件）

所有文件在：/var/data/dmp2/cdh5.3.2_install

事实证明只要这两种文件集，就足够了

（可选：把本机作为archive.cloudera.com）

$ service httpd start
$ chkconfig httpd on

创建yum源
$ vim /etc/yum.repos.d/cloudera-manager.repo
[cloudera-manager]
name=cloudera manager
baseurl=http://10.96.30.173/cloudera-manager/5.3.2
enabled=1
gpgcheck = 0

将文件scp到要安装的其它机器上

所有机器，yum clean all

其中是包括java的安装包的

安装jdk
所有节点：

$ yum install oracle-j2sdk1.7
配置Java环境变量，执行：

$ ln -s /usr/java/jdk1.7.0_67-cloudera /usr/java/default
$ echo -e ‘export JAVA_HOME=/usr/java/default’ >> /etc/profile
$ echo -e ‘export PATH=$JAV{A}_{H}OME/bin:$PATH’>> /etc/profile
$ echo -e ‘export CLASSPATH=.:$JAVA_HOME/lib’>> /etc/profile
$ source /etc/profile

之后就不用parcel再装一遍了

安装cm
master节点:10.96.30.173

$ yum install cloudera-manager-server cloudera-manager-deamons
将parcels复制到/opt/cloudera/parcel-repo

$ cp /var/www/html/parcels/5.3.2/. /opt/cloudera/parcel-repo

这句是为了在所有机器上加速安装（只用本地的，省去获取文件的时间）

所有机器上agent装不装都可以，装了比较方便一些：

$ yum -y install cloudera-manager-agent

将数据库驱动mysql-connector-java.jar放到/usr/share/java目录下，用于cloudera manager连接mysql数据库

调整数据库配置
cm节点上的/etc/cloudera-scm-server 下的两个properties文件

现在的内容，是mysql。把它改到想要恢复的mysql上，甚至可以新建库。

注意：使用cloudera-manager-installer.bin安装时，会直接启动本机的postgresql服务。其实是没必要的。

启动cm
清理掉/var/lib/cloudera-scm-server下的所有文件

$ service cloudera-scm-server start

就可以打开10.96.30.173:7180 的界面了

里面保留了scm库中的所有信息，不必再重建什么了

之后。。
就正常操作7180的界面即可

安装时，java可以跳过，不选single模式（最好指定一下本地源，会重写之前的cloudera-manager.repo）

安装如果遇到agent不响应的问题：

kill -9 $(pgrep -f supervisord)

service cloudera-scm-agent restart

这两句很有用，马上见效。

恢复
1 把scm的表，复制到scm_new目录（cm的数据库配置指向它）

2 在新机器上，安装cm和agent和java。配置数据库，并启动7180

3 使用7180的界面，将新机器加入老集群

4 删除已经异常的monitor服务。

5 在新机器上重建monitor角色并启动

6 将所有老的机器的agent配置文件：/etc/cloudera-scm-agent/config.ini 中的host指向新机器

并重启所有的agent，加一个，在7180上就能恢复一个

由此恢复了cdh的全部功能，也没有对在线业务有任何影响。