![Oracle RAC 集群数据库(10gR2、11gR2 和 12cR1)与在 Linux 集群上部署的 Oracle DB 之间的比较](https://linux22.com/image/1399098/Oracle%20RAC%20%E9%9B%86%E7%BE%A4%E6%95%B0%E6%8D%AE%E5%BA%93%EF%BC%8810gR2%E3%80%8111gR2%20%E5%92%8C%2012cR1%EF%BC%89%E4%B8%8E%E5%9C%A8%20Linux%20%E9%9B%86%E7%BE%A4%E4%B8%8A%E9%83%A8%E7%BD%B2%E7%9A%84%20Oracle%20DB%20%E4%B9%8B%E9%97%B4%E7%9A%84%E6%AF%94%E8%BE%83%20.png)
对于小型企业来说,Oracle RAC 的实施可能成本较高,但如果实施 Linux 集群,然后在该集群上部署标准 Oracle DB,以实现像 Oracle RAC 这样的可用性,情况会怎样?
是否可以在 Linux 集群上实现自动故障转移、负载平衡等?如果一个节点发生故障,Oracle DB 服务仍将提供给现有连接和新连接?
优点和缺点是什么?
答案1
这个问题很可能会引来基于观点的回答。这是其中之一。
如果在 Red Hat 集群上将 Oracle DB 进程作为服务运行,则负载平衡并不容易实现。在集群方面,您能做的最好的事情就是主动-备用,即,在任何特定时间,Oracle DB 进程只会在集群中的一个节点上运行,并且当一个节点发生故障时,进程会切换到另一个节点。不过,即使这样也可能很难实现。
负载平衡方案之所以不可行,是因为如果多个 Oracle DB 进程访问数据分区而彼此之间不了解,可能会损坏您的数据。目前,在 Oracle DB 级别让节点彼此了解的方法是购买 RAC,这就是他们出售它的原因。
也就是说,主动-备用配置可能如下所示:将 Oracle DB 进程绑定到额外的 IP 地址,然后该 IP 地址随服务从一个节点移动到另一个节点,即服务 IP 地址、Oracle DB 进程和数据分区都是 Red Hat 集群中的服务,在发生故障时从一个节点移动到另一个节点。服务 IP 为您提供了一个好处:当一个节点发生故障并由另一个节点代替时,您的客户端可以重新连接。但是,在主动-备用方案中,所有现有连接将在切换期间断开。
除了上面列出的缺点之外,还有其他问题,例如,当出现问题时很难获得 Oracle 的支持,因为您所想的场景并不是 Oracle 推荐的场景。
总而言之,重新考虑可能是个好主意,如果您确实需要 Oracle DB 级别的负载平衡等,那么购买 RAC 可能比尝试构建自己的解决方案来模仿 RAC 提供的一些功能更好。