共计 1337 个字符，预计需要花费 4 分钟才能阅读完成。
其实对于 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 即可。其它的信息都一并修改同步好，提前完成。
至于还有哪些方面需要考虑，暂且想到了图中的方方面面，可以作为我们规范备库的一个方式。
更多 Oracle 相关信息见 Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-06/132436.htm
