资料库集群，顾名思义，就是利用至少两台或者多台资料库伺服器，构成一个虚拟单一资料库逻辑映像，像单资料库系统那样，向客户端提供透明的数据服务。
基本介绍
- 中文名：资料库集群
- 利用：至少两台或者多台资料库伺服器
- 构成：一个虚拟单一资料库逻辑映像
- 分类：以Oracle RAC为代表的系统等
定义
一.资料库集群的定义
这里有两个关键点：
1. 两台或者多台资料库伺服器：如果只有一台资料库伺服器是不能称其为集群的。
2. 透明的服务：集群向客户端提供的服务与单机系统向客户端提供的服务，从通讯协定上保持二进制兼容。
二.相关名词解释
1.同步
资料库客户端发出数据更新请求后，要等集群的每个节点全部更新后，才给客户端返回结果。
2.异步
资料库客户端发出数据更新请求后，接受请求的节点(这里往往是主资料库)立马给客户端返回结果，被更新的数据则会在接下来的某个时间里被複製传输到集群的其它节点上(弱一致性处理)。
3.基于连线的负载均衡
此种负载均衡实现技术比较简单，就是在客户端发起登入的时候，按照某种负载均衡算法，选择登入到集群某台资料库，此后所有客户端的请求全部会传送到此资料库上。
4.基于请求的负载均衡
此种负载均衡实现技术比较複杂，但是功能强大，就是在客户端发起登入的时候，集群网关会同时登录到集群各节点资料库，此后所有的客户端请求，经过集群网关的分析被分成两类，查询请求根据负载均衡算法挑选一个节点执行，数据更新请求则有主机执行并实时同步数据到集群各节点。
性质
一.与分散式资料库系统的区别
- 资料库集群有的具有单份数据集，有的具有两份或多份相似的数据集，有的具有两份或多份实时一致的数据集；而分散式资料库系统往往具有完全不同的数据集。
- 资料库集群往往是同构的系统，要求集群各节点都具有相同的作业系统和资料库系统版本，甚至补丁包的版本也要求保持一致；而分散式资料库系统可以是异构系统，包含不同的作业系统和不同的资料库系统。
- 资料库集群往往建立在高速区域网路内；而分散式资料库系统既可以是高速区域网路，也可以是跨部门、跨单位的异地远程网路。
二.资料库集群的技术指标
由于资料库系统是任何一个信息系统的核心，因此除了业务逻辑之外，用户还关心下面三点：
1. 系统性能
性能问题涉及硬体、软体、网路、套用设计架构、代码质量等多方面。但是资料库集群如果能提供负载均衡能力和自动最佳化能力，则是对整个系统性能具有莫大的好处。
2. 数据可靠性
在系统发生任意故障(包括作业系统、资料库引擎、硬碟或磁碟阵列或存储网路等故障)条件下数据丢失的可能性。有的系统从设计原理上注定了必然会存在理论上的数据丢失可能性，而有的系统因为冗余设计原理，可以保证理论上的数据零丢失。用容灾领域的术语来讲，这类似于RPO(Recovery Point Objective)，但是不完全等同于RPO。
3. 服务可用性
在系统发生任意故障(包括作业系统、资料库引擎、硬碟或磁碟阵列或存储网路等故障)条件下整个系统停止对外提供数据服务的可能性。与上面的资料库可靠性紧密关联，如果一个系统从理论上存在数据丢失的可能性，那幺这样的系统必然会导致整个系统的服务停止。同样地，用容灾领域的术语来讲，这类似于RTO(Recovery Time Objective)，但是也同样不能完全等同于RTO。
三.资料库集群的分类
在市场上，资料库集群是一个笼统的名词，没有一个权威的定义，各市场参与者往往是各取所需，推出各种特色的资料库集群解决方案。一般地具有下列四种集群方案：
1．基于串列数据複製技术
串列複製技术，本来是用于数据传送和数据备份的，离人们熟悉的“资料库集群”的概念有一定的距离。但是由于计算机软硬体技术和网路通讯技术的快速发展，使得利用这种概念和技术构成的“资料库集群”有了一定的可行性。此类集群，又可以分两类:
a.串列异步複製
此种方式是数据的异步串列複製。主要採用资料库事务日誌传送或者硬碟数据块传送技术来实现，SQL Server自带的複製、镜像和SQL2012新出的AlwaysON(备机可读)以及第三的一些镜像Mirror技术都是属于此类产品，此类技术和产品本质上就是数据备份技术和产品。下列以事务日誌传送(Log Shipping)为例来说明。主资料库完成事务处理后，生成事务处理日誌，日誌记录通过FIFO伫列，进入备份资料库处理，从而得到备份数据。此种方式的缺陷在于：
a) 主资料库并行处理事务而日誌拷贝是串列的，而备份资料库处理日誌记录也是串列的。因此，FIFO伫列的溢出随时可能发生。一旦发生，伫列必须重建，从而需要重新建立备份资料库。此种方法对于一般客户来讲是不可行的。
b) 由于日誌拷贝是异步的，主备资料库不是实时一致，两者之间存在“时间差”，因此如果用备份资料库作负荷均衡，这样的套用存在逻辑上的漏洞，可能会发生数据错乱。
c) 由于主备数据存在时间差, 主资料库一旦发生事故，理论上一定会丢失数据。在这种情况下，要幺需要手工恢複数据库，这会消耗大量的人工成本，或者数据根本就不能恢复。
d) 对主机的性能影响，根据测试一般在15%到25%之间。
b.串列同步複製
此类集群往往是由昂贵的专用软硬体构成的，原理图如下：
此类系统採用专用的高速网路和软体技术，将每个资料库的请求，通过同步複製的方式，同步在主备两台资料库伺服器上执行正确后，才将结果返回给资料库客户。此系统的特点是：
a) 主资料库被强迫与备份资料库同步串列处理，因此性能受到限制。
b) 主备资料库中任意一个出现问题，都会迫使事务处理交易回滚，因此整个系统的可靠性比单机系统降低了一半。
c) 由于以上问题，这种备份方式只适用于近距离光纤网路（5英里）。
d) 专用系统造价昂贵，又加上述明显缺陷，因此市场上很少被採用。
2．基于共享存储的双机容错技术
从技术适应性的角度讲，双机容错比较适合于无状态套用，或者状态信息较少的套用切换，以此达到套用级的高可用性目的，其实并不适合于资料库级的套用切换。
此种结构往往是两个伺服器共享一个磁碟阵列，这里两个伺服器共享一个虚拟的IP供资料库客户使用，形成一个单一的逻辑资料库映象。此种所谓的资料库集群的目的是，一旦主机系统出现问题，备份系统通过心跳机制的检测，完成从主机系统到备份系统的切换。这种方案在市场上被称为“双机集群”或者“双机热备”，简称参见“双机”，但微软称之为“故障转移集群”。它有下列特点：
a. 此种高可用性解决方案只是无状态系统(典型的如Web伺服器)的普通容错切换思想在资料库领域的套用。
b. 此系统本身只有一个单一的数据映象，数据储存在共享的磁碟阵例上，因此共享的磁碟阵列成为了整个系统的单点错误源。
c. 由于是单一数据映象，因此必须採用通常的複製或备份方法获取第二份数据，以保证数据的安全性。因此所有複製或备份方法的缺点，此类系统全部存在。
d. 主机系统和备份系统之间是没有任何负载均衡关係的，在正常情况下，备份系统是闲置在那里，因此对用户来说是一种投资浪费。
e. 在错误切换的时候，往往存在切换时间长，而且更严重的是可能会存在丢失用户交易数据丢失的现象，结果导致系统被迫停止服务，或者需要人工修複数据，或者数据永远找不回来。
3．以Oracle RAC为代表的系统
RAC的英文全称是：Real Application Cluster(真正的套用级集群)。我们需要关注的是“套用级”。为了缓解资料库系统日益增长的性能压力，Oracle公司推出了RAC系统。它基本结构如下：
此类系统，专门是针对资料库性能问题而提出的。採用共享磁碟阵列的方式，因此在结构上和上述双机容错相似，不同的地方在于此系统中的资料库节点之间採用的不是简单的心跳检测，而是Oracle公司自己定义的一套複杂的信息交换协定，以此来动态分配来自资料库客户端的请求。它的特点是：
a. 是个套用级的集群，也就是针对Oracle的资料库管理系统(因为资料库管理系统对于作业系统来讲，就是一个“应用程式”，因此被称为“套用级集群”)，专门为提高资料库性能而设计。
b. 此系统本身只有一个单一的数据映象，数据储存在共享的磁碟阵例上，因此享的磁碟阵例成为了整个系统的单点错误源。
c. 管理配置複杂。
d. 由于是单一数据映象，因此必须採用通常的複製或备份方法获取第二份数据，以保证数据的安全性。因此所有複製或备份方法的缺点，此类系统全部存在。
e. 由于资料库系统本身具有高I/O的特性，因此，RAC系统里，磁碟I/O是提高性能的关键地方。
f. 依据不同的资料库套用，有的性能有所提升，有的性能可能会反而下降。
套用
一．基于实时数据同步技术
基于此技术构造的资料库集群是市场上的新兴力量，它又具有两类，分别是：
a.具有独立网关
下面以DBTwin为例来说明其技术特点。
DBTwin採用了冗余设计原理，对于来自客户端的请求，请求被分成两类：查询请求和数据更新请求。对于数据更新请求，集群内部各节点之间保持数据的实时同步一致；对于数据的查询请求，则可以在集群各节点之间负载均衡执行。它的特点是：
a) 负载均衡的单元是客户端的每个独立请求，这点除了Oracle RAC集群，是市场上独有的。
b) 实时冗余一致的多份数据，从理论上讲实现了数据的零丢失。
c) 由于可以做到数据零丢失，因此在系统发生任意故障条件下，可以做到系统的对外服务不停止。
d) 此系统使用了专用高速数据同步技术，根据测试，数据同步速度能SQL Server的镜像相等。
e) 此系统的缺点是数据同步需要花费代价,节点数量受到限制，一般2到4个节点为宜。
f) 此系统从巨观上提升了整个系统的性能。
b.将调度节点集成于资料库引擎
下面以Moebius来说明其技术特点。
任何在资料库和应用程式之间引入的中间件都同时引入了单点故障点，如果中间件（网关）出现了故障，则资料库集群就会形同虚设。因此Moebius在集群中的每个节点上都存在于嵌入于资料库引擎的分发代理，当前负责调度的分发代理出现故障时，分发代理会故障转移到集群中的其他节点，从而避免了使用网关架构所引入的单点故障点，除此之外，该类产品的特点是：
a) 负载均衡是基于每个客户端的独立请求，默认规则是将查询优先分发到集群中负载低的伺服器，也可以自定义规则，将某些特定业务分发到集群中的某一台，比如将报表相关的查询分发给集群中的特定伺服器。
b) 採用Share-Nothing架构，对数据进行冗余，从而保证了数据的安全性
c) 资料库同步机制採用日誌Redo的方式，在日誌同步之前对日誌进行压缩，保证了同步效率
d) 在集群中任意节点出现故障时，会被自动剥离出节点，由剩余运行正常的节点继续提供服务，从而保证了最小停机时间
e) 负载均衡集群从巨观上提高了吞吐量和性能
f) 该类集群不需要特殊的存储设备，可以使用廉价的本地存储，但由于数据冗余，因此相较于Share-Disk架构而言，需要更多的存储空间
c.没有独立网关
当前市场上也存在下列一种基于数据实时同步的集群，其拓扑结构如下图所示：
此系统由于没有独立的集群网关，因此本质上简化成了资料库的实时备份系统，与实际的备份系统不同的是，它是工作在资料库套用层。此系统的特点：
a) 没有独立的集群网关，通过主节点的转发来实行查询的负载均衡。在系统压力大的情况下，集群主机会形成性能瓶颈，无论是CPU、记忆体还是网路频宽，也可能是OS等系统核心资源，都容易因到达临界状态而形成瓶颈。
b) 各节点数据实时一致，对于数据容错有利。
c) 对客户端没有二进制透明。
d) 负载均衡单元是资料库连线。也就是说，在客户端登入资料库的时候，静态地指定连线到某个集群节点，此后此连线上的全部请求一律传送到该资料库上，因此在特殊情况下，可能会出现这样的场景：所有客户端的连线集中在集群主机上，这时候，集群主机不但承担了客户端的所有查询，还需要实时同步数据到所有的集群从机，即集群主机的CPU为100%，而集群别的节点CPU可能为0%，这样整个系统的性能会受到严重影响。
e) 由于使用的是分散式事务机制(MSDTC)确保数据的实时一致性，因此数据同步的性能比较慢，根据测试,会比SQL Server镜像慢好几倍。
f) 同样地，此集群的节点数量也受到限制，也是以2到4个节点为宜。