wjy0 2018-10-20
背景
UDDB(UCloud分布式数据库)产品的测试环境中有一个zk集群, 三节点。 某一天其中一个zk节点所在云主机崩溃了,无法启动。只好重装系统盘。
zk的执行码在系统盘上。为此重新安装了zk软件。 apt-get install zookeeper 即可。
zk的配置文件(zoo.cfg),三节点都是一样的, 从其他zk节点拷贝一份过来即可。
zk存储的数据在数据盘上。根据zk的崩溃恢复机制, 存储的老数据可以删除,在zk重启后由其他zk节点再同步过来即可。
因此,从开始到结束, 执行了以下操作:
1. apt-get install zookeeper
2. 修改/etc/hosts , 配置ip 和zoo.cfg中主机名的对应关系:
zoo.cfg中的配置是:
server.1=10-10-182-162:2888:3888
server.2=10-10-150-34:2888:3888
server.3=10-10-149-63:2888:3888
于是在/etc/hosts增加:
10.10.182.162 10-10-182-162
10.10.150.34 10-10-150-34
10.10.149.63 10-10-149-63
3.删除了zk的老数据:
rm -rf /data/zookeeper/version-2
但保持/data/zookeeper/myid 这个文件不变(用来存储这个zk节点的id)。
4.启动zk:
cd /usr/share/zookeeper/bin
bash zkServer.sh stop
bash zkServer.sh start
zk进程能够成功启动,但是启动后用zkCli.sh 登陆,无法 ls /:
查看/var/log/zookeeper/zookeeper.log, 有以下报错:
查看网上资料,指出该问题原因大多为新启动的zk节点无法加入到集群中。但是为何无法加入,原因各异,又始终无法和我这个问题匹配起来。
分析
带着这个问题,查看了另外2个zk节点的日志,其中有:
注意到红框中的日志。从该日志看, 像是底层网络就出现异常了。为何会出现异常? 我lsof -p 三个zk进程,发现第一个崩溃重启后的进程,其3888端口竟然是:
是绑定了localhost端口。
再看下 /etc/hosts 发现之前的配置是有问题的:
在增加:
10.10.182.162 10-10-182-162
10.10.150.34 10-10-150-34
10.10.149.63 10-10-149-63
时,忘记删除 127.0.0.1 10-10-182-162 这个配置项。导致10-10-182-162这个主机名,依然解析到127.0.0.1。
解决
把该配置项删除,然后重启zk节点,问题得到解决, 通过zkÇli.sh 执行: ls / 没有问题。
总结
1.zk节点崩溃后重启,不需要先同步数据(直接把之前老的数据删除即可),在zk重启后,将从其他zk节点自动同步数据;
2.配置时一定要仔细,查问题时多看日志多用心分析。
双臂问问题
ZooKeeper支持某些特定的四字命令字母与其的交互。它们大多是查询命令,用来获取ZooKeeper服务的当前状态及相关信息。用户在客户端可以通过telnet或nc向ZooKeeper提交相应的命令