转载自   沃趣科技(woqutech)

作者       周天鹏   


笔者上一篇译文中在介绍Leaf Node时提到, 虽然leaf node不要求直接访问共享存储,但最好还是连上共享存储,因为说不准未来哪天就要把这个leaf node转为hub node使用。 其实这样的说法并不够准确,在12cR1时,leaf node上是无法运行只读数据库实例的,这时不连接共享存储完全不影响其使用。而12cR2的leaf node是可以运行只读数据库实例的,一旦leaf node上有了数据库,这时leaf node(确切的说这时leaf node应该叫做reader node)就必须连接共享存储了。

这次就介绍下如何将节点的角色在hub node和leaf node之间互相转换。由于笔者实验环境中已经存在了一个leaf node,所以先从leaf node转为hub node做起。

初始状态:


Leaf 转 Hub

该集群上运行着名为orcl的数据库,在角色转换之前先观察下orcl库的状态:

显然,由于rac3现在是leaf node,所以rac3上的数据库实例只能以只读方式打开。

执行如下操作即可将rac3的角色从leaf node转为hub node

crsctl set node role {hub | leaf}

查看各节点角色信息:

 根据命令输出信息可知,在配置生效前需要重启该节点的crs,即角色转换无法在线进行。

关闭rac3的crs服务:

查看各个节点角色信息:

启动rac3的crs服务:

启动完成后在查看各个节点角色信息:

此时观察下整个集群的状态:

此时rac3上的orcl库的实例已变为open状态,而不是之前的Open,Readonly。


Hub转Leaf

在12cR2中,如果想将一个节点角色设置为leaf node,那么该集群的scan解析方式必须为GNS。
通过上面的整个集群的状态信息也可以看出笔者的实验环境是配置了GNS的。如果未配置,执行crsctl set node role leaf命令时将报错。

 同上,rac3依然需要重启crs来使配置生效。
过程略。
重启后各个节点角色信息如下:

此时整个集群状态如下:

可以发现在rac3切换为leaf node之后,多了ora.LISTENER_LEAF.lsnr这个资源,而且rac3上的asm实例是不启动的,db实例又变成了readonly方式打开。
需要注意的一点是,leaf node上的只读db实例会把服务注册到LISTENER_LEAF这个监听中,而不是LISTENER。
所以lsnrctl status的输出结果始终看不到任何已注册的服务。

最后需要注意的是:leaf node上默认监听端口为1525。


结  论

  • 转换节点角色需要重启该节点crs。

  • 12cR2中节点转换为leaf node要求必须配置GNS。

  • Leaf node上的asm实例是不会启动的,db实例只能以只读方式启动。

  • 12cR1中还需要手动更新inventory,12cR2中已不再需要,角色修改操作大幅简化。