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=
J
A
V
A
H
O
M
E
/
b
i
n
:
JAVA_HOME/bin:
JAVAHOME/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的全部功能,也没有对在线业务有任何影响。