oracle的高可用与负载均衡

浏览了一下Oracle官方的网页以及非官方的ppt，简单了解了一下Oracle提供的高可用方案。
1. RAC
RAC,  Real Application Clusters
多个Oracle服务器组成一个共享的Cache，而这些Oracle服务器共享一个基于网络的存储。这个系统能够容忍单机/或是多机失败。
不过系统内部的多个节点须要高速网络互连，基本上也就是要所有东西放在在一个机房内，或者说一个数据中心内。若是机房出故障，好比网络不通，那就坏了。因此仅仅用RAC仍是知足不了通常互联网公司的重要业务的须要，重要业务须要多机房来容忍单个机房的事故。

2. Data Guard.
Data Guard这个方案就适合多机房的。某机房一个production的数据库，另外其余机房部署standby的数据库。Standby数据库分物理的和逻辑的。物理的standby数据库主要用于production失败后作切换。而逻辑的standby数据库则在平时能够分担production数据库的读负载。

3. MAA
MAA(Maximum Availability Architecture)其实不是独立的第三种，而是前面两种的结合，来提供最高的可用性。每一个机房内部署RAC集群，多个机房间用Data Guard同步。

Oracle+Fusionio+Dataguard的高可用方案
传统的Oracle的高可用方案必须基于共享存储设备，不论是双机主备模式，仍是Oracle RAC，数据库必须放在共享的SAN存储上，经过HA或集群软件实现高可用。Oracle DataGuard是很好的容灾软件，可是做为HA解决方案，功能有不少局限性，好比数据丢失，应用透明切换，只能读没法写(11g)等等，目前都没有很是好的解决方案。
自从固态存储技术出现后，单机的IO能力大幅度提高，好比采用PCIE接口的fusionio卡，单块卡就能够提供数万IOPS的能力，单机的IO能力已经超过了传统的磁盘存储。可是，一直困扰咱们的是，如何解决无共享存储环境下Oracle数据库的高可用问题？咱们团队设计了一种架构，提供简单可靠的高可用功能。

虽然在Oracle的立场上，老是建议客户可以更好地规划本身的应用，在有其它负载平衡方法的时候，尽可能不要依赖于Oracle的Load Balance方法，可是每每在给客户配置完Oracle RAC数据库之后，客户都会要求要测试负载平衡（Load Balance）和TAF（Transparent Application Failover），而且将这两个测试做为RAC是否安装成功的标准。
这是一件很无奈的事情，像把旁枝末节看做了主要功能，甚至有些买椟还珠的感受，可是毕竟这是客户，更了解Oracle Load Balance（后文用LB表示），才能够更好知足客户需求。

RAC的负载均衡主要是指新会话链接到RAC数据库时，如何断定这个新的链接要连到哪一个节点进行工做。在RAC中，负载均衡分为两种，一种是基于客户端链接的，另一种是基于服务器端的。客户端的负载均衡配置相对简单，只须要在tnsnames.ora中添加LOAD_BALANCE=ON这么一个选项便可。

实现负载均衡(Load Balance)是Oracle RAC最重要的特性之一，主要是把负载平均分配到集群中的各个节点，以提升系统的总体吞吐能力。
一般状况下有两种方式来实现负载均衡
一个是基于客户端链接的负载均衡
客户端的负载均衡主要是经过为tnsnames.ora增长load_balance=yes条目来实现
若是未开启load_balance=yes时，Oracle Net会根据地址列表按顺序来选择一个进行链接，直到链接成功为止。 若是第一个host主机链接失败，在有多个地址的情形下，接下来选择第二个地址链接，依此类推，直到链接成功为止。当开启了load_balance=yes时，则Oracle Net会从多个地址中随机地选择一个地址进行链接，直到链接成功为止。注意，此链接方式仅根据地址列表随机选择，并不考虑到各个实例上当前真正链接数量的多少，也便是没有考虑各个节点真实的链接负载状况

二是基于服务器端监听器(Listener)收集到的信息来将新的链接请求分配到链接数较少实例上的实现方式。
Oracle RAC服务器端的负载均衡是根据RAC中各节点的链接负荷数状况，将新的链接请求分配到负荷最小的节点上去。当数据库处于运行时，RAC中各节点的PMON进程每3秒会将各自节点的链接负荷数更新到service_register。而对于节点中任意监听器故障或监听器意外失败时，PMON进程会每1秒钟检查当前节点上的监听是否重启，以得到最新的负载信息来及时调整负载均衡。

跨机房问题

跨机房问题一直都是一个老大难的问题，先看传统数据库的跨机房方案。

Master/Slave方案

这是最经常使用的方案，适用于大多数需求。Master将操做日志实时地发送到Slave，Slave当成Master的一个Hot Backup。Master宕机时，服务切换到Slave，须要修改客户端逻辑使得Master失效时自动寻找新的Master。

这个方案有一个问题就是数据库的Master和Slave通常不是强同步的，因此，切换到Slave后可能丢失宕机前的少许更新。若是将 Master和Slave作成强同步的，即：全部的数据必须同时写成功Master和Slave才成功返回客户端，这样又带来了另一个问 题：Master和Slave中任何一台机器宕机都不容许写服务，可用性太差。所以，Oracle有一种折衷的模式：正常状况下Master和Slave 是强同步的，当Master检测到Slave故障，好比Slave宕机或者Master与Slave之间网络不通时，Master本地写成功就返回客户 端。采用这种折衷的同步模式后，通常状况下Master和Slave之间是强同步的，Master宕机后切换到Slave是安全的。固然，为了确保数据安 全后，宕机的Master重启后能够和新的Master(原有的Slave)对比最后更新的操做日志，若是发现不一致能够提醒DBA手工介入，执行数据订 正过程。

Master和Slave之间强同步还有一个问题就是跨机房延时，对于关键业务，同城的机房能够部署专用光纤，在硬件层面上解决这个问题；异地的机房通常用来作备份，与主机房之间的数据同步通常是异步的，可能有秒级延时。

机房宕机切换自动化成本过高，可是对于不少单点服务，机房内部宕机切换的自动化颇有必要。Oceanbase采用Linux的一个开源方 案：Pacemaker，经过heartbeat和虚IP漂移的方式实现机房内部宕机自动切换。因为主备切换本质上是一个选主问题，理论上只有Paxos 或者相似协议能够解决，而Pacemaker没有采用复杂的Paxos协议，它对硬件是有依赖的，好比要求主备节点之间经过直连线保证网络不会发生故障， 而这在机房内部是能够作到的。机房之间采用前面提到的Master/Slave方案，能够写一个脚本ping主机房的Master，当确认主机房 Master宕机时(好比一分钟不通)将服务切换到备机房并报警。