共计 898 个字符,预计需要花费 3 分钟才能阅读完成。
环境:RHEL6.2 + Vertica 6.1.3-7
1. 确定所有节点的 vertica 进程都停掉(包括 agent 和 python),如果有运行的,停止它或者杀掉它。
2. 确定所有节点的 spread 进程都正常在运行。
3. 用 admintools 工具启动数据库到 LGE
1. 确定所有节点的 vertica 进程都停掉(包括 agent 和 python),如果有运行的,停止它或者杀掉它。
数据库为关闭状态,也就是停库后,如果还有进程,可以
ps -ef|grep vertica |grep -v spread|awk ‘{print $2}’|xargs kill -9
这样可以强制杀掉除了 spread 的 vertica 进程。
2. 确定所有节点的 spread 进程都正常在运行。
确定下所有节点的 spread 服务都是启动的,
/etc/init.d/spreadd status
如果有未启动的就启动一下 [使用 root 用户],
/etc/init.d/spreadd start
3. 用 admintools 工具启动数据库到 LGE
admintools -> 7.Advanced Menu -> 1.RollBack Database to Last Good Epoch -> 选择数据库,输入数据库密码 -> Restart epoch(注意这个 Epoch 如果和日志分析的有区别,不要进行操作,找原厂支持)
另外发现在 Vertica 的 7.x 版本中,spread 进程停库就没了,而 6.x 的 spread 是和数据库分开的。所以 7.x 版本的管理更加简单,一般情况,不需再考虑 spread 进程的状态(7.x 版本的 spread 进程随库启动,也不需要 root 用户)。
本次应用场景:数据库正常启动不成功,一开始各个节点状态是 INITIALIZING,之后各个节点陆续均成为 LOSTCONTACT 状态,分析日志 adminTools-dbadmin.log 以及各节点的 vertica.log。
最终分析的 LGE 与数据库启动到 LGE 自动识别出的 LGE 相同,按照原厂工程师的指导操作,最终启动成功。
本文永久更新链接地址 :http://www.linuxidc.com/Linux/2015-09/122608.htm