标签归档:gpnp

11.2中修复CRS不能启动的例子-1-使用正常节点的gpnp profile修复损坏节点

SSD上的一个11.2 RAC的其中一个节点OS不能起来了,鼓捣半天还是不行 想想这个是2013年买的,才两年啊……,不知道是不是这个原因,反正很无语…… 另一个10多年前的活动硬盘上那个RedHat 2上的Oracle 8.0.6都还可以使用 . 就这个环境,从其他活动硬盘上复制了节点1的老的备份到SSD上,尝试修复整个RAC。 由于只修改了节点1的IP跟我现在VBOX中的配置一致即可,且节点2是正常的,因此,无需大招。 只要两件事情; 1,在OS层面修改节点1的网络配置: 2,把节点2的gpnp profile传给节点1 . 具体如下: 1,将2个节点的crsd都关闭,把节点2的profile.xml复制到节点1: 确认节点2的crs是关闭的: 2,确认当前的节点2的gpnp profile信息是正确的: 我这里主要是私有网络的IP地址应该为192.168.20.0网段: 即 可见这里是正确的。 注意这里,当所有CRS进程都不启动时,gpnp的信息来自于他自己的一个cache(猜测这个是从文件上保存的profile中读取到他自己的所谓cache的) . 3,查看节点1当前的gpnp profile,注意,其中的net2的信息,是错误的: 4,确认节点1的crs全部都是关闭的: 5,备份节点1当前的gpnp profile: 6,将节点2的gpnp profile复制到节点1: 7,启动节点1和节点2的crs(正常启动即可): 8,可以看到,节点1已经可以正常启动了: 这里看到节点1的网络信息也正常了 再启动节点2: 除了network2(用于ADG的网络,还没有修改相应的配置),其他都正常了。

发表在 RAC | 标签为 , , , | 留下评论