关键词: RAC 升级、人大金仓、RAC集群
问题描述
某三方测试项目需要证明RAC集群具备离线升级能力,根据前期同事的滚动升级测试用例,调整出了离线升级的测试用例,进行测试验证。
升级操作流程简单总结如下:
①暂停数据库服务(crm resource stop clone-DB)、
②备份升级前的二进制文件(每个节点执行)、
③将二进制文件对应的路径替换为新版本、
④启动数据库服务,验证业务是否恢复。
升级操作完成后,数据库服务启动失败
问题分析
2. 根据报错信息,检查kingbase.conf文件是否有损坏,确认conf文件升级前后未发生任何变化;
3. 使用sys_controldata指令,查看升级前后的controlfile,确认升级前后的controlfile均能够正常打开
4. 将升级前后的controlfile导出(具体操作方式:分别使用升级前后的二进制文件的sys_controldata导出data目录至文件a和文件b)
cd {版本1的rac集群二进制文件部署目录};./sys_controldata -D {基于gfs2部署的data目录} >a.text
cd {版本2的rac集群二进制文件部署目录};./sys_controldata -D {基于gfs2部署的data目录} >b.text
5. 使用vimdiff指令,对比文件a和文件b,
Vimdiff a.text b.text
对比发现旧版本仅支持4节点集群,新版本支持的的是8节点集群(项目中其他特性需求,后期版本合入)
解决方案
使用支持8节点集群的版本重新部署集群作为初始版本, 启动成功。
思考总结:
controlfile的信息根据数据库实时状态,受多方面影响。