转载:【Oracle 集群】RAC知识图文详细教程(一)--集群概念介绍

文章导航

转载自：http://www.cnblogs.com/baiboy/p/orc1.html\html

转载目的：便于本人对看到的好文章进行分类整理，及根据实际须要进行进行适当的调整或补充，不用于适合商业用途。node

集群术语须知

服务硬件：指提供计算服务的硬件，好比 PC 机、PC 服务器。mysql

服务实体：服务实体一般指服务软体和服务硬体。sql

节点（node）：运行 Heartbeat 进程的一个独立主机称为节点，节点是 HA 的核心组成部分，每一个节点上运行着操做系统和Heartbeat 软件服务。数据库

资源（resource）：资源是一个节点能够控制的实体，当节点发生故障时，这些资源可以被其余节点接管。如：磁盘分区、文件系统、IP 地址、应用程序服务、共享存储缓存

事件（event）：事件也就是集群中可能发生的事情，例如节点系统故障、网络连通故障、网卡故障和应用程序故障等。这些事件都会致使节点的资源发生转移，HA 的测试也是基于这些事件进行的。安全

什么是集群

集群（cluster）就是一组计算机，它们做为一个总体向用户提供一组网络资源，这些单个的计算机系统就是集群的节点（node）。集群提供了如下关键的特性。服务器

(一) 可扩展性。集群的性能不限于单一的服务实体，新的服务实体能够动态的加入到集群，从而加强集群的性能。网络

(二) 高可用性。集群经过服务实体冗余使客户端免于轻易遭遇到“out of service”警告。当一台节点服务器发生故障的时候，这台服务器上所运行的应用程序将在另外一节点服务器上被自动接管。消除单点故障对于加强数据可用性、可达性和可靠性是很是重要的。架构

(三) 负载均衡。负载均衡能把任务比较均匀的分布到集群环境下的计算和网络资源，以便提升数据吞吐量。

(四) 错误恢复。若是集群中的某一台服务器因为故障或者维护须要而没法使用，资源和应用程序将转移到可用的集群节点上。这种因为某个节点中的资源不能工做，另外一个可用节点中的资源可以透明的接管并继续完成任务的过程叫作错误恢复。

分布式与集群的联系与区别以下：

(一) 分布式是指将不一样的业务分布在不一样的地方。

(二) 而集群指的是将几台服务器集中在一块儿，实现同一业务。

(三) 分布式的每个节点，均可以作集群，而集群并不必定就是分布式的。而分布式，从狭义上理解，也与集群差很少，可是它的组织比较松散，不像集群，有必定组织性，一台服务器宕了，其余的服务器能够顶上来。分布式的每个节点，都完成不一样的业务，一个节点宕了，这个业务就不可访问了。

集群主要分红三大类：

HA：高可用集群（High Availability Cluster）。

LBC：负载均衡集群/负载均衡系统（Load Balance Cluster）

HPC：科学计算集群（High Performance Computing Cluster）/高性能计算（High Performance Computing）集群。

为何搭建数据库集群

随着经济的高速发展，企业规模的迅猛扩张，企业用户的数量、数据量的爆炸式增加，对数据库提出了严峻的考验。对于全部的数据库而言，除了记录正确的处理结果以外，还面临着如下几方面的挑战。

l 如何提升处理速度，实现数据库的均衡负载。
l 如何保证数据库的可用性、数据安全性、以及如何实现数据集群可扩性。
l 怎么综合解决这些问题成为众多企业关注的焦点。

在数据库上，组建集群也是一样的道理，主要有如下几个缘由：

(一) 伴随着企业的成长，业务量提升，数据库的访问量和数据量快速增加，其处理能力和计算速度也相应增大，使得单一的设备根本没法承担。

(二) 在以上状况下，若扔掉现有设备，作大量的硬件升级，势必形成现有资源的浪费，并且下一次业务量提高时，又将面临再一次硬件升级的高额投入。因而，人们但愿经过几个中小型服务器组建集群，实现数据库的负载均衡及持续扩展；在须要更高数据库处理速度时，只要简单的增长数据库服务器就能够获得扩展。

(三) 数据库做为信息系统的核心，起着很是重要的做用，单一设备根本没法保证系统的下持续运行，若发生系统故障，将严重影响系统的正常运行，甚至带来巨大的经济损失。因而，人们但愿经过组建数据库集群，实现数据库的高可用，当某节点发生故障时，系统会自动检测并转移故障节点的应用，保证数据库的持续工做。

(四) 企业的数据库保存着企业的重要信息，一些核心数据甚相当系着企业的命脉，单一设备根本没法保证数据库的安全性，一旦发生丢失，很难再找回来。因而，人们但愿经过组建数据库集群，实现数据集的冗余，经过备份数据来保证安全性。

数据库集群的分类

数据库集群技术是将多台服务器联合起来组成集群来实现综合性能优于单个大型服务器的技术，这种技术不但能知足应用的须要，并且大幅度的节约了投资成本。数据库集群技术分属两类体系：基于数据库引擎的集群技术和基于数据库网关（中间件）的集群技术。在数据库集群产品方面，其中主要包括基于数据库引擎的集群技术的 Oracle RAC、Microsoft MSCS、IBM DB2UDB、Sybase ASE，以及基于数据库网关（中间件）的集群技术的 ICX-UDS 等产品。

通常来说，数据库集群软件侧重的方向和试图解决的问题划分为三大类：

l 负载均衡集群（Load Balance Cluster，LBC）侧重于数据库的横向扩展，提高数据库的性能。
l 高可用性集群（High Availability Cluster，HAC）侧重保证数据库应用持续不断。大部分的数据库集群侧重与此。
l 高安全性集群（High Security Cluster，HSC）侧重于容灾。

只有 Oracle RAC 能实现以上三方面

可扩展的分布式数据库架构

(一) Oracle RAC：

其架构的最大特色是共享存储架构（Shared-storage），整个 RAC 集群是创建在一个共享的存储设备之上的，节点之间采用高速网络互联。OracleRAC 提供了很是好的高可用特性，好比负载均衡和应用透明切块（TAF），其最大的优点在于对应用彻底透明，应用无需修改即可切换到RAC 集群。可是RAC 的可扩展能力有限，首先由于整个集群都依赖于底层的共享存储，因此共享存储的 I/O 能力和可用性决定了整个集群的能够提供的能力，对于 I/O 密集型的应用，这样的机制决定后续扩容只能是 Scale up（向上扩展）类型，对于硬件成本、开发人员的要求、维护成本都相对比较高。Oracle显然也意识到了这个问题，在 Oracle 的 MAA（Maximum Availability Architecture）架构中，采用 ASM 来整合多个存储设备的能力，使得 RAC 底层的共享存储设备具有线性扩展的能力，整个集群再也不依赖于大型存储的处理能力和可用性。

RAC 的另一个问题是，随着节点数的不断增长，节点间通讯的成本也会随之增长，当到某个限度时，增长节点可能不会再带来性能上的提升，甚至可能形成性能降低。这个问题的主要缘由是 Oracle RAC 对应用透明，应用能够链接集群中的任意节点进行处理，当不一样节点上的应用争用资源时，RAC 节点间的通讯开销会严重影响集群的处理能力。因此对于使用 ORACLE RAC 有如下两个建议：

l 节点间通讯使用高速互联网络；
l 尽量将不一样的应用分布在不一样的节点上。

基于这个缘由，Oracle RAC 一般在 DSS 环境（决策支持系统Decision Support System ，简称DSS)中能够作到很好的扩展性，由于 DSS 环境很容易将不一样的任务分布在不一样计算节点上，而对于 OLTP 应用（On-Line Transaction Processing联机事务处理系统），Oracle RAC 更多状况下用来提升可用性，而不是为了提升扩展性。

(二) MySQL Cluster

MySQL cluster 和 Oracle RAC 彻底不一样，它采用无共享架构Shared nothing（shared nothing architecture）。整个集群由管理节点(ndb_mgmd)，处理节点(mysqld)和存储节点(ndbd)组成，不存在一个共享的存储设备。MySQL cluster 主要利用了 NDB 存储引擎来实现，NDB 存储引擎是一个内存式存储引擎，要求数据必须所有加载到内存之中。数据被自动分布在集群中的不一样存储节点上，每一个存储节点只保存完整数据的一个分片(fragment)。同时，用户能够设置同一份数据保存在多个不一样的存储节点上，以保证单点故障不会造成数据丢失。MySQL cluster 主要由 3 各部分组成：

l SQL 服务器节点
l NDB 数据存储节点
l 监控和管理节点

这样的分层也是与 MySQL 自己把 SQL 处理和存储分开的架构相关系的。MySQL cluster 的优势在于其是一个分布式的数据库集群，处理节点和存储节点均可以线性增长，整个集群没有单点故障，可用性和扩展性均可以作到很高，更适合 OLTP 应用。可是它的问题在于：

l NDB（“NDB” 是一种“内存中”的存储引擎，它具备可用性高和数据一致性好的特色。）存储引擎必需要求数据所有加载到内存之中，限制比较大，可是目前 NDB 新版本对此作了改进，容许只在内存中加载索引数据，数据能够保存在磁盘上。
l 目前的 MySQL cluster 的性能还不理想，由于数据是按照主键 hash 分布到不一样的存储节点上，若是应用不是经过主键去获取数据的话，必须在全部的存储节点上扫描，返回结果处处理节点上去处理。并且，写操做须要同时写多份数据到不一样的存储节点上，对节点间的网络要求很高。

虽然 MySQL cluster 目前性能还不理想，可是 share nothing 的架构必定是将来的趋势，Oracle 接手 MySQL以后，也在大力发展 MySQL cluster，我对 MySQL cluster 的前景抱有很大的期待。

(三) 分布式数据库架构

MySQL 5 以后才有了数据表分区功能（Sharding）， Sharding 不是一个某个特定数据库软件附属的功能，而是在具体技术细节之上的抽象处理，是水平扩展(Scale Out，亦或横向扩展、向外扩展)的解决方案，其主要目的是为突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。好比 Oracle 的 RAC 是采用共享存储机制，对于 I/O 密集型的应用，瓶颈很容易落在存储上，这样的机制决定后续扩容只能是 Scale Up（向上扩展）类型，对于硬件成本、开发人员的要求、维护成本都相对比较高。Sharding 基本上是针对开源数据库的扩展性解决方案，不多有据说商业数据库进行 Sharding 的。目前业界的趋势基本上是拥抱 Scale Out，逐渐从 Scale Up 中解放出来。

Sharding 架构的优点在于，集群扩展能力很强，几乎能够作到线性扩展，并且整个集群的可用性也很高，部分节点故障，不会影响其余节点提供服务。Sharding 原理简单，容易实现，是一种很是好的解决数据库扩展性的方案。Sharding 并非数据库扩展方案的银弹，也有其不适合的场景，好比处理事务型的应用它可能会形成应用架构复杂或者限制系统的功能，这也是它的缺陷所在。读写分离是架构分布式系统的一个重要思想。很多系统总体处理能力并不能同业务的增加保持同步，所以势必会带来瓶颈，单纯的升级硬件并不能一劳永逸。针对业务类型特色，须要从架构模式进行一系列的调整，好比业务模块的分割，数据库的拆分等等。集中式和分布式是两个对立的模式，不一样行业的应用特色也决定了架构的思路。如互联网行业中一些门户站点，出于技术和成本等方面考虑，更多的采用开源的数据库产品(如 MYSQL)，因为大部分是典型的读多写少的请求，所以为 MYSQL 及其复制技术大行其道提供了条件。而相对一些传统密集交易型的行业，好比电信业、金融业等，考虑到单点处理能力和可靠性、稳定性等问题，可能更多的采用商用数据库，好比 DB2、Oracle 等。就数据库层面来说，大部分传统行业核心库采用集中式的架构思路，采用高配的小型机作主机载体，由于数据库自己和主机强大的处理能力，数据库端通常能支撑业务的运转，所以，Oracle 读写分离式的架构相对MYSQL 来说，相对会少。读写分离架构利用了数据库的复制技术，将读和写分布在不一样的处理节点上，从而达到提升可用性和扩展性的目的。最一般的作法是利用 MySQL Replication 技术，Master DB 承担写操做，将数据变化复制到多台 Slave DB上，并承担读的操做。这种架构适合 read-intensive 类型的应用，经过增长 Slave DB 的数量，读的性能能够线性增加。为了不 Master DB 的单点故障，集群通常都会采用两台 Master DB 作双机热备，因此整个集群的读和写的可用性都很是高。除了 MySQL，Oracle 从 11g 开始提供 Active Standby 的功能，也具有了实现读写分离架构的基础。读写分离架构的缺陷在于，无论是 Master 仍是 Slave，每一个节点都必须保存完整的数据，如果在数据量很大的状况下，集群的扩展能力仍是受限于单个节点的存储能力，并且对于 Write-intensive 类型的应用，读写分离架构并不适合。

采用 Oracle 读写分离的思路，Writer DB 和 Reader DB 采用日志复制软件实现实时同步； Writer DB 负责交易相关的实时查询和事务处理，Reader DB 负责只读接入，处理一些非实时的交易明细,报表类的汇总查询等。同时，为了知足高可用性和扩展性等要求，对读写端适当作外延，好比 Writer DB 采用 HA 或者 RAC 的架构模式，目前，除了数据库厂商的集群产品之外，解决数据库扩展能力的方法主要有两个：数据分片和读写分离。数据分片(Sharding)的原理就是将数据作水平切分，相似于 hash 分区的原理，经过应用架构解决访问路由和Reader DB 能够采用多套，经过负载均衡或者业务分离的方式，有效分担读库的压力。

对于 Shared-nothing 的数据库架构模式，核心的一个问题就是读写库的实时同步；另外，虽然 Reader DB只负责业务查询，但并不表明数据库在功能上是只读的。只读是从应用角度出发，为了保证数据一致和冲突考虑，由于查询业务模块可能须要涉及一些中间处理，若是须要在数据库里面处理(取决与应用需求和设计)，因此Reader DB 在功能上仍然须要可写。下面谈一下数据同步的技术选型问题：

能实现数据实时同步的技术不少，基于 OS 层(例如 VERITAS VVR)，基于存储复制(中高端存储大多都支持)，基于应用分发或者基于数据库层的技术。由于数据同步可能并非单一的 DB 整库同步，会涉及到业务数据选择以及多源整合等问题，所以 OS 复制和存储复制多数状况并不适合作读写分离的技术首选。基于日志的 Oracle 复制技术，Oracle 自身组件能够实现，同时也有成熟的商业软件。选商业的独立产品仍是 Oracle 自身的组件功能，这取决于多方面的因素。好比团队的相应技术运维能力、项目投入成本、业务系统的负载程度等。

采用 Oracle 自身组件功能，无外乎 Logical Standby、Stream 以及 11g 的 Physical Standby(Active Data Guard)，对比来讲，Stream 最灵活，但最不稳定，11g Physical Standby 支持恢复与只读并行，但因为并非日志的逻辑应用机制，在读写分离的场景中最为局限。若是技术团队对相关技术掌握足够充分，而选型方案的处理能力又能支撑数据同步的要求，采用 Oracle 自身的组件彻底可行。选择商业化的产品，更多出于稳定性、处理能力等考虑。市面上成熟的 Oracle 复制软件也无外乎几种，不管是老牌的 Shareplex，仍是本土 DSG 公司的 RealSync 和九桥公司的 DDS，或是 Oracle 新贵 Goldengate，都是可供选择的目标。随着 GoldenGate 被 Oracle 收购和推广，我的认为 GoldenGate 在容灾、数据分发和同步方面将大行其道。固然，架构好一个可靠的分布式读写分离的系统，还须要应用上作大量设计，不在本文讨论范围内。

(四) CAP 和 BASE 理论

分布式领域 CAP 理论：

l Consistency(一致性), 数据一致更新，全部数据变更都是同步的
l Availability(可用性), 好的响应性能
l Partition tolerance(分区容错性) 可靠性

定理：任何分布式系统只可同时知足二点，无法三者兼顾。

忠告：架构师不要将精力浪费在如何设计能知足三者的完美分布式系统，而是应该进行取舍。

关系数据库的 ACID 模型拥有高一致性 + 可用性很难进行分区：

l Atomicity 原子性：一个事务中全部操做都必须所有完成，要么所有不完成。
l Consistency 一致性. 在事务开始或结束时，数据库应该在一致状态。
l Isolation 隔离层. 事务将假定只有它本身在操做数据库，彼此不知晓。
l Durability. 一旦事务完成，就不能返回。

(五) 跨数据库事务

2PC (two-phase commit)， 2PC is the anti-scalability pattern (Pat Helland) 是反可伸缩模式的，也就是说传统关系型数据库要想实现一个分布式数据库集群很是困难，关系型数据库的扩展能力十分有限。而近年来不断发展壮大的 NoSQL（非关系型的数据库）运动，就是经过牺牲强一致性，采用 BASE 模型，用最终一致性的思想来设计分布式系统，从而使得系统能够达到很高的可用性和扩展性。那么，有没有可能实现一套分布式数据库集群，既保证可用性和一致性，又能够提供很好的扩展能力呢？

BASE 思想的主要实现有按功能划分数据库 sharding 碎片BASE 思想主要强调基本的可用性，若是你须要 High 可用性，也就是纯粹的高性能，那么就要以一致性或容错性为牺牲，BASE 思想的方案在性能上仍是有潜力可挖的。

l 共同点：都是关系数据库 SQL 之外的可选方案，逻辑随着数据分布，任何模型均可以本身持久化，将数据处理和数据存储分离，将读和写分离，存储能够是异步或同步，取决于对一致性的要求程度。
l 不一样点：NOSQL 之类的 Key-Value 存储产品是和关系数据库头碰头的产品 BOX，能够适合非 Java 如 PHP RUBY等领域，是一种能够拿来就用的产品，而领域模型 + 分布式缓存 + 存储是一种复杂的架构解决方案，不是产品，但这种方式更灵活，更应该是架构师必须掌握的。

目前，已经有不少分布式数据库的产品，可是绝大部分是面向 DSS 类型的应用，由于相比较 OLTP 应用，DSS 应用更容易作到分布式扩展，好比基于 PostgreSQL 发展的 Greenplum，就很好的解决了可用性和扩展性的问题，而且提供了很强大的并行计算能力。对于 OLTP 应用，业务特色决定其要求：高可用性，一致性，响应时间短，支持事务和 join 等等。数据库和 NoSQL当愈来愈多的 NoSQL 产品涌现出来，它们具有不少关系型数据库所不具有的特性，在可用性和扩展性方面均可以作到很好。

第一，NoSQL 的应用场景很是局限，某个类型的 NoSQL 仅仅针对特定类型的应用场景而设计。而关系型数据库则要通用的多，使用 NoSQL 必须搞清楚本身的应用场景是否适合。

第二，利用关系型数据库配合应用架构，好比 Sharding 和读写分离技术，一样能够搭建出具有高可用和扩展性的分布式数据库集群。

第三，关系型数据库厂商依然很强大，全世界有大量的用户，需求必然会推进新的产品问世。

第四，硬件的发展突飞猛进，好比闪存的技术的不断成熟，将来闪存能够做为磁盘与内存之间的 cache，或者完全替代磁盘。而内存价格愈来愈低，容量愈来愈大，In-memory cache 或 database 的应用愈来愈普遍，能够给应用带来数量级的性能提高。数据库面临的 IO 问题将被极大改善。

转载自：http://www.cnblogs.com/baiboy/p/orc1.html\

转载目的：便于本人对看到的好文章进行分类整理，及根据实际须要进行进行适当的调整或补充，不用于适合商业用途。