Data Guard中快速Switchover,Failover的一些建议(r9笔记第29天)

其实对于Failover和Switchover是大家处理灾难时很头疼的一个环节，也是最关键的处理过程。 假设你半夜正在睡觉，被报警电话惊醒，得知某个服务器产生了故障宕机，在这种情况下，我们大体会有下面的处理流程： 1）检查原来的节点是否可用，需要查看ILO和存储，是否存在异常 2）如果原来的节点可以重启，可以尽量马上恢复业务，然后分析根本原因，是否是硬件老化，硬件故障导致，如果发现问题影响较大，可以使用Switchover 3）如果原来的节点无法重启，这个时候需要考虑Failover,如果在同机房可以直接替换IP，异地机房需要配合开发，系统运维来修改应用连接IP 4) 配合系统，开发，检查业务是否恢复正常 这个时候有几个问题就摆在了眼前 1）原来库的防火墙信息在Failover之后，备库本身是没有的。这个怎么办，一种临时解决办法就是关闭防火墙，然后允许应用都连接进来，在后台收集连接服务器信息和端口，收集到一定程度之后，开启防火墙，另外一种方式就是从历史的备份中找到，开启防火墙 2）Switchover,Failover之后，主备库的多监听端口是否一致，要不数据库间通信没问题，很可能应用连接的端口不一而导致连接问题 3）主备库切换后，部分db link不可用，究其原因还是tnsnames.ora中的主机名配置不够统一，缺少权限导致。 还有更多的细节问题，比较参数文件不统一，内核参数文件不统一导致的配置问题，性能问题。 所以我们需要快速Swithover,Failover,数据的切换之外，这些额外的工作花费的时间要远多于切换。

当然我之前也分析过命令的方式切换，也写过一些脚本辅助。从根本上来说，Switchover和Failover的差别很小，对于备库来说都是透明的，只是一种状态标示。所以我们可以简化switchover和Failover的一些内容，其实操作上来说，主要的区别就是是否修改IP,switchover可能会替换IP,而Failover可能会修改备库IP为原来的主库IP在这一点上看起来不好统一，其实进一步分析，如果我们使用主机名的方式在listenerora,tnsnames.ora，那么在/etc/hosts中只需标记一次即可，替换就修改/etc/hosts的配置，否则不修改。 而其它的信息就会更加清晰，都提前同步好了，准备好了。 那么可能会有一个问题，就是主库已经是线上业务，这个怎么统一啊，而且处理不当会弄巧成拙，这个担忧是很对的，对于主库没有200%的把握不要修改主库的这些信息，主库不能改动，备库可以啊。所以我们可以从备库的层面来规范，始终保证这些配置信息在备库都是标准，规范的配置。这样一来在宕机事件面前，我们 的操作及混简单，决定是switchover还是failover即可。其它的信息都一并修改同步好，提前完成。 至于还有哪些方面需要考虑，暂且想到了图中的方方面面，可以作为我们规范备库的一个方式。