关于Oracle和MySQL的高可用方案，其实我一直想总结一下，下面分几个系列简单说一下他们。通过这样的对比，你会对两种数据库架构在设计上的细节差异有一个基本的了解。Oracle有一个非常成熟的解决方案。根据我在OOW上的ppt，是MAA项目，今年是这个项目的16周年。由于MySQL的开源特性，社区也推出了更多的解决方案。个人认为，InnoDBCluster将会是MySQL未来高可用解决方案的标配。目前MGR肯定不错，另外还有MySQLCluster解决方案，PXC，Galera等解决方案。我个人更喜欢MHA。因此，本文将分成几个部分来解读，先拿RAC和MHA做一个基本的比较。Oracle的解决方案支撑了阿里高速发展时期的核心业务需求。大概这样的架构体系看起来很大。里面的RAC算是贵族了。它使用昂贵的商业存储，需要极高的网络带宽，前端有大量小型计算机服务，还有昂贵的许可费用。非常典型的IOE经典架构。如果要考虑异地容灾，资源配置一定要加倍，预算也要加倍。MySQL的架构方案相对更加平民化。普通PC还好，只是数量级更高。业务拆分和横向拆分可以横向扩展很多节点。很多大型互联网公司的MySQL集群规模有几百、几百、几千的规模并不少见。服务资源那么多，还是有失败的可能。确保对业务服务的可持续访问是技术解决方案的关键。按照MHA的架构，MHAManager节点基本上负责整个集群的状态，就像居委会的阿姨一样，对居民的大小事了如指掌。当然，上面的说法太笼统了，还是从一些细节说起吧。比如先说网络。Oracle对网络的要求还是很严格的。一般需要2块物理网卡。每个服务器至少需要3个IP，PublicIP、PrivateIP、VIP。除了共享存储，至少还需要2个计算节点。私有IP是节点之间的相互信任。公网IP和VIP在同一网段。简单的说，VIP是外部的，是公网IP所在网络的浮动IP。在10g中，VIP用于负载均衡。从11g开始有了scan-IP，原来的VIP还是保留的，所以Oracle里面的网络配置要求还是很高的。除了共享存储，构建的核心是网络配置，网络是通用的。scan-IP可以继续扩展，最多支持3个scan-ip，如下图。当然，网络层面不仅仅局限于这些，Oracle在这方面是非常专业的。我们有必要了解TAF。在我的《Oracle DBA工作笔记》一书中，我写道：TAF（TransparentApplicationFailover）是Oracle中对应用程序透明的故障转移，在RAC环境中应用尤其广泛。RAC中的LoadBalance确实有了很大的提升。从10g版本开始的多个VIP地址的LoadBalance，到11g版本的SCAN，都做了很大的简化。在Failover的实现中，还是有一定的使用限制的。比如11g中SCAN-IP的默认实现其实默认是没有Failover这个选项的。如果两个节点中的一个挂掉了，原来的连接会继续查询会提示会话已经断开，需要重新连接。ClientTAF主要讨论了FailoverMethod和FailoverType的一些简单内容。(1)FailoverMethodFailoverMethod的主要思想是通过换取failover时间，或者换取资源来实现。可以这样理解，假设我们有两个节点，如果一个session连接到节点2，但是节点2突然挂了，为了更快的处理Failover的情况，FailoverMethod有两种：preconnect和basic.—preconnect方式还是会占用大量资源，在每个节点上都会预占一些额外的资源，切换会相对更顺畅和快速。—基本方法中，当发生Failover时，切换相应的资源。中间会有一些滞后，但是资源消耗相对要小很多。简单来说，basic方法只会在出现故障时才进行判断，而preconnect则是为了未雨绸缪；从实际应用来看，basic方式更为通用，也是默认的failover方式。(2)FailoverTypeFailoverType的实现更丰富、更灵活，也非常强大。此时可以根据用户SQL的执行情况来控制控制粒度。有两种类型：select和session；让我用一个小例子来说明。比如我们在节点2上做一个大查询，结果节点2突然挂了。比如正在执行的查询，有10000条数据，结果发现刚好发生故障时检测到了8000条数据，那么剩下的2000条怎么办。第一种方式是使用select；即完成故障转移，继续返回剩余的2000条记录。当然，中间还会有一些上下文切换，对用户是透明的。第二种方式是session；即直接断开连接，要求重新查询。在10g版本中，借助VIP配置的LoadBalance+Failover配置如下：racdb=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.3.101)(PORT=1521))(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.3.201)(PORT=1521))(LOAD_BALANCE=yes)(FAILOVER=ON)(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=racdb)(FAILOVER_MODE=(TYPE=SELECT)(METHOD=BASIC)(RETRIES=30)(DELAY=5))))如果11gSCAN-IP还想进一步扩展Failover，还需要设置failover_mode和对应的type。RACDB=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=rac-scan)(PORT=1521))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=RACDB)))从这个角度来看，Oracle的解决方案是真的很好。我们来看看MySQL的解决方案。分布式解决方案使MySQL看起来像一把瑞士刀。对于网络层面的要求，可以说MySQL没有要求。如果申请一主一从，只需要4个IP（master，slave，VIP，MHA_Manager（考虑是manager节点）），一主两从是5个，此时MySQL原生不支持so-称为负载平衡。可以通过前端服务进行分发，比如使用中间件代理，或者连续拆分。达到一定粒度后，再通过架构设计来满足需求。因为基于逻辑的复制容易扩展，一主多从很普遍，成本也不高。延迟不能说不存在，但是很低，可以满足大部分互联网业务的需求。至于触发MHA切换的条件，从网络的角度来看，以下红点是潜在的隐患。有些是网络中断，有些是网络延迟。根据您自己的需要定制。从这个角度来看，有丢失数据的可能。绝对不是强一致性无损复制。两种方案整体来看，RAC是集中共享。除了存储层面的共享，网络层面的组播实际上会增加节点间通信的成本。因此，RAC对网络的需求很大。如果有延误，那是非常危险的，脑裂很尴尬。MySQLMHA解决方案是分布式的。支持大容量环境，节点间通信的成本相对要低很多。但是从数据架构来看，因为是复制的数据分布方式，虽然存储不是共享存储，但是存储的成本还是比RAC高（不是存储的价格，而是存储的数据量）.
