高可用概述
高可用技术——RAC
- 多个实例同时提供服务，一个实例崩溃不会影响数据库的可用性
- 设计合理的RAC环境可以避免单点故障对系统的影响
- RAC的ROLLING UPDATE支持不停机升级补丁
高可用技术——DATAGUARD
- 和RAC环境搭配是高可用系统的最佳配置
- 解决了人力不可抗拒的灾难发生后系统的可用性问题
- 快速的解决人为引入的错误
- 逻辑STANDBY可以用来进行快速升级
Oracle Data Guard 和 Oracle 真正应用集群 (RAC) 彼此互补。RAC 解决系统或例程故障。它提供不影响数据的故障（如节点故障或例程崩溃）的快速和自动恢复。它还为应用程序提供增强的可伸缩性。另一方面，Data Guard 通过使用在事务上一致的主数据库和备用数据库 — 它们既不共享磁盘也不运行在锁步模式下 — 提供数据保护。这使得从站点灾难或数据损坏中恢复成为可能。
高可用之维护—充分利用STANDBY数据库
利用STANDBY数据库实现读写分离，避免大的查询操作对在线系统的影响。STANDBY数据库可以只读打开，类似报表查询等只读操作可以部署到STANDBY数据库
11G中STANDBY数据库可以在只读打开的同时应用日志，查询可以随时看到最新的修改
利用STANDBY进行备份，可以降低备份操作对主环境的影响
实例配置方式
数据库实例配置
- 一个实例只能用于访问一个数据库
- 一个数据库可能对应着一个或多个实例（RAC架构）
RAC
在不同服务器（节点）上运行的多个实例
共享存储器上的单一数据库可供所有节点访问
实例通过互连网络交换信息
Real Application Clusters
RAC体系结构
一个Oracle RAC(Real Application Clusters )数据库系统，在硬件层面主要由四个部分组成：
共享存储：主要存放数据库的数据，每个RAC节点都可以访问共享存储上的数据。
RAC 节点：即多台单独的计算机，通过私网彼此互联，从而构成一个整体来对外提供服务。
私网：也叫“内联网络”（interconnect），将RAC节点互相连接，实现节点间的相互通讯，从而使RAC构成一个集群。
公网：也称之为“服务网络”，客户端程序通过公网访问数据库。
作为一个集群，参与集群的成员必须保证能够正常工作，从而保证共享资源可以被统一的、有协调的更改。
为增强RAC系统的高可用性，需要对这四个组成部分分别通过一定的手段来提高其高可用性，从而提高RAC系统的高可用性。
脑裂
脑裂（split-brain）是指发生了某些故障后，RAC从一个统一工作的集群分裂为多个独立工作的子集群，这样就会破坏共享资源的数据一致性。
为避免出现“脑裂”情况，当发现某个节点已经不能与其它节点协调工作时，RAC会将该节点从集群中逐出（节点驱逐 node eviction），从而维护共享资源的一致性。
节点一旦被隔离之后，在11gR2之前通常是重启故障节点。而在11gR2中，ClusterWare会首先尝试关闭该节点的所有资源，尝试对集群中失败的组建进行清理，即重启失败的组件。如果清理失败的组件未成功，为了强制清理，则再对节点进行重启。 节点驱逐：
首先Cluster member(如RAC instance)请求Oracle Clusterware 重启指定Member (kill member) 从11.2.0.2将会减少reboot node取而代之的是尝试graceful shutdown GI，然后OHASD 会尝试restart the stack(GI) after the graceful shutdown
如果member kill unsuccessful，此时node eviction会请求升级，尝试重启Node包含以下几种情况：
1）如果检查成功终止IO进程失败→重新启动
2）如果CSSD在→重新启动的操作中被杀死
3）IF cssdmonitor（oprocd替换）未计划→重新启动
4）如果堆栈无法在"short_disk_timeout"秒内关闭→重新启动
心跳机制
RAC通过心跳机制可以避免“脑裂”。心跳机制可以验证：
私网是否在正常通讯。
RAC 节点本身是否在正常工作。
共享存储是否在正常工作。
RAC有两种心跳机制：
网络心跳：检查私网与RAC节点是否正常。
磁盘心跳：检查位于共享存储上的Vote Disk是否正常
OCSSD是一个管理及提供Cluster Synchronization Services (CSS)服务的Linux或者Unix进程。使用Oracle用户来运行该进程并提供节点成员管理功能，一旦该进程失败，将导致节点重启。CSS服务提供2种心跳机制，一种为网络心跳，一种为磁盘心跳。两种心跳都有最大延时，网络心跳的延时叫MC(Misscount)， 磁盘心跳延时叫作IOT (I/O Timeout)。 这2个参数都以秒为单位，缺省时情况下Misscount < Disktimeout。下面分别描述这2种心跳机制。
网络心跳（Network heartbeat）的工作机制：
正常情况下集群节点每秒钟要发出一次心跳（或者说被ping一次）。
如果在由CSS Misscount 参数限定的时间内（默认30秒）心跳信息没有返回，则认为该节点当前工作不正常，出现了心跳超时。
对于心跳超时的节点，集群会将其驱逐。
出现网络心跳超时的一般原因：
私网网络方面的问题：如网络端口、网卡、网线、交换机等。
主机hang或者超过30秒没有响应。
主机CPU、内存以及IO资源严重不足。
如果心跳网络断掉了，oracle的集群就会分裂成若干个小的自己群，我们叫cohort(你可以在ocssd.log)里面找到。 oracle会根据每个cohort包含的节点数量决定哪个子集群离开，基本的原则是：
1. 节点数多的子群留下，节点数少的被驱逐。
2. 如果每个子集群的节点数相同，那么包含了最小节点编号的节点会被保留。
为了提高私网的高可用性，避免网络心跳超时，可以采取：
- 网卡绑定：由主机厂商提供
- Oracle Redundant Interconnect(HAIPs )： Oracle的解决方案
- 一个节点上配置多个private IP，高可用，负载均衡 规范要求不使用HAIP功能
- 判重策略问题
- HAIP Oracle 已知bug 参见：note 1640865.1 for Known HAIP issues in 11gR2/12c Grid Infrastructure
通过上述配置，在发生如下故障时RAC系统不受影响：
- 单个交换机故障
- 某个主机上的单个网卡故障
- 某台主机上单个网卡到交换机的链路故障
Oracle Redundant Interconnect(HAIPs )
Oracle的解决方案：从11.2.0.2开始提供
每个服务器最多支持4个网卡，可以使用不同的子网，可以使用VLAN
同时支持Load Balancing和Failover 由于Oracle在HAIP（169.254地址）判重策略问题，造成了数据中心新上线系统IP和已上线系统IP冲突，影响了生产。为了避免该问题，要求新安装的RAC彻底取消HAIP的使用
磁盘心跳 （Disk heartbeat）的工作机制：
正常情况下集群节点每秒钟更新一次表决磁盘（vote disk）。
共享的表决磁盘用于检查磁盘心跳，位于ASM的SYS磁盘组的3块磁盘上。
如果更新表决磁盘的时间超过由CSS disktimeout 参数限定的时间（默认200秒），则认为该表决磁盘脱机offline，出现磁盘心跳超时。
如果当前节点表决磁盘脱机的个数小于在线表决磁盘的个数，该节点能够幸存；如果脱机表决磁盘的个数大于或等于在线表决磁盘的个数，则集群认为磁盘心跳出现问题，故障节点会被逐出集群。
出现磁盘心跳超时的一般原因：
存储方面的问题，存储链路，HBA卡等
主机hang或者超过200秒没有响应
下面是CSSD进程日志文件中的一个示例：
[cssd(9240642)]CRS-1615:No I/O has completed after 50% of the maximum interval. Voting file /dev/rhdiskpower0 will be considered not functional in 99143 milliseconds
CSS（ocssd） 进程负责管理集群成员，监控集群健康情况。
ocssd是一个多线程（thread）的进程，其中Disk Ping thread和Disk Ping Monitor thread负责监控管理磁盘心跳。
Disk Ping thread每秒钟向vote disk写入信息，以表明当前节点正常工作；同时还会从vote disk中的“kill block”中读取信息。
Disk Ping Monitor thread负责监控Disk Ping thread是否正常读取“kill block”，如果发现Disk Ping thread 不能读取vote disk的“kill block”信息，说明IO有问题，如果超时达到timeout（缺省为200s），那么会将vote disk offline，这就是磁盘心跳超时。
为提高共享存储的高可用性，避免磁盘心跳超时，可以采取冗余机制：
利用ASM磁盘组的冗余模式
利用ASM的失效磁盘组：即把不同盘柜的盘加入不同的失效组，实现更好的冗余。
ASM磁盘组具有三种冗余模式：
外部冗余：由磁盘阵列负责实现数据的冗余（传统方式）
Normal冗余模式：即实现数据的镜像
High冗余模式：即实现数据的三重镜像
由于Voting disk直接放置在磁盘上，Normal冗余模式下必须有3个voting disk，分布在3块磁盘上。由于已经有了3份，Oracle不再象数据的Normal冗余模式一样，再写镜像，因此Voting disk的数量总是奇数个。当使用存储保护而不引入NAS时，总有一边机柜上会有>1/2的voting disk，这样当该机柜宕机时，由于RAC每个节点所能看到的voting disk都<1/2，此时必然导致两个节点同时宕机，无法实现存储保护的目的。在这种情况下，引入NAS来存储第三块voting disk，当任意一边存储机柜宕机时，都有两个voting disk可用，RAC不会宕机。
心跳与主机重启算法小结：
网络心跳每秒钟向其他节点发送信息，包含时间标记，同时也接受其他节点发来的信息，网络心跳超时30秒。
- crsctl get css misscount
- CRS-4678: Successful get misscount 30 for Cluster Synchronization Services.
磁盘心跳每秒钟更新vote信息，包含时间标记。磁盘心跳在vote盘等待写超时，使用200秒长超时。
-crsctl get css disktimeout
-CRS-4678: Successful get disktimeout 200 for Cluster Synchronization Services. 当私网超时大于30秒，在11.2.0.2版本后首先尝试重启CRS，如果CRS无法正常停止则此时尝试重启主机。
当vote盘写超时200秒，在11.2.0.2版本后首先尝试重启CRS，如果CRS无法正常停止则此时尝试重启主机。
Virtual IP
虚拟IP地址，浮动的，实现应用的高可用。
VIP 每分钟检验一次，当节点停止或者公网不可用时，VIP自动漂移至另一个节点。
Ifconfig、entstat、netstat
当检测到网络恢复，VIP漂回。
应用连接使用VIP地址，应用需要支持自动重连。
11g RAC需要的IP如下：
每节点各需要VIP 1个，public IP 1个，private IP 1个（不使用HAIP功能）；
每套RAC共用SCAN IP 1个；
其中VIP 、public IP、SCAN IP要求在同一网段；private IP必须和以上IP不在同一网段， private IP在同一网段；
双节点RAC共计IP：7个
网卡需求：物理机器需要6个网卡。VIP 、public IP、SCAN IP共用一个双网卡绑定网卡，private IP使用一个双网卡绑定网卡，带管IP使用一个双网卡绑定网卡。虚拟环境由于已经对网卡进行了虚拟化，只需要3个
设有一个2个节点的RAC，正常运行时每个节点上都有一个VIP。 VIP1 和VIP2. 当节点2发生故障，比如异常关系。 RAC 会做如下操作：
1). CRS 在检测到rac2节点异常后，会触发Clusterware 重构，最后把rac2节点剔除集群，由节点1组成新的集群。
2). RAC的Failover 机制会把节点2的VIP转移到节点1上，这时节点1的PUBLIC 网卡上就有3个IP 地址： VIP1,VIP2, PUBLIC IP1.
3). 用户对VIP2的连接请求会被IP层路由转到节点1
4). 因为在节点1上有VIP2的地址，所有数据包会顺利通过路由层，网络层，传输层。
5). 但是，节点1上只监听VIP1和public IP1的两个IP地址。并没有监听VIP2，故应用层没有对应的程序接收这个数据包，这个错误立即被捕获。
6). 客户段能够立即接收到这个错误，然后客户段会重新发起向VIP1的连接请求。
常用RAC管理命令
