rac 启动数据库-rac的crs启动

专注Java领域优质技术，欢迎关注

来自：OceanBase技术闲谈

1 简介

本文总结了几种常用的关系型数据库架构及其演化历史。

分析数据库架构方案的几个角度是故障时的高可用性、数据的一致性和切换后的可扩展性。 每种产品也有其独特的优点和特点，在此不再赘述。

2. Oracle数据库架构方案

ORACLE数据库可以同时运行OLTP和OLAP服务，其能力在商业数据库中名列前茅。 支持IBM小型机和x86 PC服务器，支持多操作系统。 同时，有多种数据库架构方案可供选择，成本、收益和风险各不相同。

A. IBM AIX HACMP + ORACLE9I + EMC

图 1：IBM AIX HACMP + ORACLE9I + EMC

架构说明：

1、两台IBM AIX A和B，AIX A运行Oracle Primary实例，AIX B分配一些资源虚拟出一个OS C来运行Oracle Standby实例。 AIX B 的大部分剩余资源都可以免费用于将来的另一个 OraclePrimary 实例。

2.两个存储（EMC只是一个例子）A和B分别直连两个AIX A和B。 Storage A存储了Primary实例的日志和数据，同时也存储了Standby实例的Redo（图中没有显示，只有当角色不是Primary时才有效）。 Storage B存储Standby实例的日志和数据，同时也存储Primary实例的Redo文件。

3、AIX也可以换成普通的x86_64 PC服务器，HACMP可以换成支持linux的集群软件。 比如Veritas HA。

功能：

1、高可用：当Oracle Primary实例不可用时，HACMP在AIX B上启动Oracle Primary实例。当存储A不可用时，将AIX C上的Standby实例故障转移到Primary实例。

2. 数据一致性：重做文件在两个存储上都保留。 Standby 实例在故障转移之前应用 Primary Redo。 理论上，即使发生故障转移也不会丢失数据。

3、可扩展性：数据库的性能由主机AIX和存储容量决定，两者都可以向上扩展，成本会急剧上升，而且有上限。

B. x86 + ORACLE RAC + EMC

架构说明：

1、两台主机A和B可以是AIX或者普通的x86_64 PC服务器。 它们直接相互连接，同时连接到共享存储EMCA。 A 和 B 分别运行一个 RAC Primary 实例。

2、Host C可以是一台AIX或者x86_64普通PC服务器，直接连接另一个存储B，运行一个Standby实例。 一些架构也有多个 Standby 实例，其中一个也是 RAC。

功能：

1、高可用：无论哪个Oracle RACPrimary实例不可用，另一个都可以自动接管服务。 如果主实例的存储A不可用，则将备实例故障转移到主实例。

2、数据一致性：如果Primary实例也输出一组Redo成员到B存储，理论上不会丢失数据。 否则，在极端情况下，可能会因为缺少主事务日志而导致 Failover 失败。 这种情况下，直接将备实例激活为主实例，可能会丢失少量数据。

3、可扩展性：如果数据库的计算能力不足，可以水平扩展（增加RAC节点），如果存储容量不足，可以向上扩展（存储扩展）。

C. Oracle Dataguard 共享重做

架构说明：

1、普通x86服务器A和B分别运行Oracle的Primary和Standby实例。 它们直接相互连接并同时连接到共享存储。

2. Primary和Standby实例的Redo、control files、spfiles放在共享存储上，占用空间很小。 数据文件放在本地机器上，一般是高速存储（比如SSD或者PCIE接口的Flash设备）。

功能：

1、高可用：当Primary实例不可用时，将Standby实例故障切换为Primary实例。 如果共享存储不可用，则两个实例都不可用。 通常有第三个备用实例。

2、数据一致性：在Failover之前将Primary实例的Redo文件应用到Standby实例rac 启动数据库，事务日志不丢失，数据强一致性。

3. 可扩展性：无。

三、MySQL数据库架构方案

A. ADHA（阿里巴巴数据库高可用）

架构说明：

1、采用MySQL Master-Master架构，双向同步，Slave只读。

2、使用Zookeeper集群监控实例不可用，防止脑裂。

功能：

1、高可用：Master实例不可用后，Slave被激活。 可用性优先。 如果Slave延迟超过一定阈值，则放弃切换。 zk集群的三节点部署可以防止脑裂。

2、数据一致性：为了尽可能少的减少数据丢失，建议开启单向半同步技术。 同时，旧master恢复后，会尽量将没有及时同步到新master上的数据补上。 由于同步依赖Binlog，理论上无法保证主从数据的绝对一致性。

3、可扩展性：可以读写分离，可以添加slave来扩展读服务能力。

B. MHA（Master High Availability）

架构说明：

1、源于MySQL主从同步架构，采用半同步技术，所以至少有两个从实例（Slave）。 所以整体架构是一主两从，两个从库不是级联关系。

功能：

1、高可用：当Master不可用时，自动从两个Slave中选择包含Binlog最多的Slave，提升为Master。 同时，将另一个Slave的Master换成新的Master。 当Master异常时，如果拉取到Slave上的Binlog丢失（当master或slave发生故障时），很容易造成复制中断，所以这种高可用机制并不是一直有效。

2、数据一致性：为了尽量减少Binlog的丢失，建议使用半同步技术进行主从同步。 在网络异常的情况下，半同步可能会退化为异步同步。 MHA只是尽力确保数据不丢失。 并且由于同步依赖Binlog，理论上无法保证主从数据严格一致。

3、可扩展性：可提供读写分离服务，可添加从节点扩展读服务能力。

C. PXC（Percona XtraDB 集群）

架构说明：

1. 允许两个节点，建议三个节点（防止裂脑）组成一个Cluster。 三个节点同时提供读写服务。 数据是三个独立的副本，不是共享存储。

2、交易提交是同步复制，所有从节点同步提交。

功能：

1、高可用：三个节点同时提供读写服务，任何一个节点都不会受到影响。

2、数据一致性：数据强同步到所有节点，不丢失数据。 需要主键，部分SQL不支持同步。

3、可扩展性：事务提交是同步复制，其性能仅限于最差的节点。

4.其他：多主复制，但同一行数据不能同时写入（乐观锁，会报死锁错误）。 此外，还有写入放大的缺点。

4、分布式数据库中间件架构方案

A.分布式数据库DRDS

架构说明：

1、DRDS Server节点是一组响应SQL请求并进行分库分表路由转换、SQL改写、聚合计算等的无状态程序。支持库表二级维度拆分，支持多种灵活拆分策略，支持分布式事务。

2、MySQL节点主要用于存储数据，主备节点之间采用双向同步架构。 此外，MySQL PaaS平台提供高可用切换和自动化运维能力。

3.围绕这个架构还有一个数据同步组件（经纬），实现了小表广播和异构索引表的能力。

4、最新版架构在只读实例的基础上实现了MPP并行计算引擎，支持部分OLAP查询场景。

功能：

1、高可用：计算节点（DRDS Server节点）的高可用通过前端负载均衡设备实现，存储节点（MySQL）的高可用通过ADHA实现。 RTO在40s左右，RPO>=0。

2、数据一致性：MySQL主备同步是半同步还是异步。 ADHA 将 MySQL 故障切换时主备不一致的概率降到最低。 理论上不能保证绝对一致性，RPO>=0。

3. 可扩展性：计算和存储节点可以单独扩展。 存储扩展是通过增加MySQL实例和数据迁移和重新分布来实现的。

4、运维：发生故障时，主备强制切换后，有一定概率会因为数据不一致导致主备同步中断。

B.分布式数据库TDSQL

架构说明：

1、计算节点：由一组无状态网关节点组成，负责SQL路由和MySQL master故障时的路由切换。

2、调度系统：使用zk集群进行元数据管理、故障监控、数据库故障转移、弹性伸缩任务等。

3、存储节点：MySQL主备架构，一主两从，强同步或异步同步。

4.支持全时数据模型

功能：

1、高可用：网关前端估计也有负载均衡，MySQL主备切换依赖zk判断，RTO在40s左右

2、数据一致性：一主两备采用强同步时，基本可以保证RPO=0。 如果是异步的，切换可能会有延迟。

3. 可扩展性：通过增加网关的能力或数量来增加计算能力，增加MySQL节点的数量进而调整数据分布来提高计算和存储能力。

4、运维：当出现异常时，可能会因为数据不一致导致主备同步服务中断，需要修复。

C.分布式数据库GoldenDB

架构也是分库分表，和DRDS基本一样。

D.分布式数据库MyCat

架构原理和功能与前两类基本相同。 底层存储节点也支持Oracle和Hive。

E.分布式数据库HotDB

5.分布式数据库

A.谷歌的F1

阐明：

1、F1支持sql，底层可以支持MySQL和Spanner。 选择Spanner的主要原因是Spanner不需要手动分区，使用Paxos协议同步数据，保证强一致性和高可用。

2. Spanner分为多个Zone部署。 每个区域都有一个 zonemaster（管理元数据和 spannerserver）和多个 spannerservers。

3. Spanner的数据存储在tablet中，每个tablet按照固定的大小分成多个目录。 Spanner以目录为单位进行负载均衡和高可用，paxos groups与目录对应。

4. Spanner的TrueTime设计为分布式事务的实现提供了新的方向（分布式MVCC）。

B. PingCap 的 TiDB

TiDB主要参考了Google的Spanner和F1的设计，在架构上有很多相似之处。

架构说明：

1. TiDB server 负责处理 SQL 和路由。 无状态，可以部署多个节点，结合负载均衡设计，对外提供统一的访问地址。

2. PD Server 是集群的管理模块，负责存储元数据，为 TiKV 进行任务调度和负载均衡，分配全局唯一且增量的事务 ID。

3. TiKV Server是一个存储节点，从外部看是一个Key-Value存储引擎。 表数据按照固定大小（比如 20M，可配置）自动划分为多个 Region，分布在多个 TiKV Server 上。 Region是数据迁移和高可用的最小单位。 Region的内容一共有三份，分布在三个区域。 数据同步和强一致性由Raft协议保证。

4. 支持分布式事务，率先实现全局一致的快照。 支持全局一致的备份。

5、兼容MySQL主要语法。

功能：

1、可用性：计算节点无状态部署，结合负载均衡设计，保证高可用和负载均衡。 存储节点部署三副本，使用Raft协议保持三副本的数据一致性和同步性，并在出现故障时自动进行选举（高可用）。

2、可扩展性：计算和存储分离，可以独立扩展。 存储节点扩容后，数据会重新分布，需要后台异步任务完成，不影响业务读写，可以在线扩容。 可用于异地容灾，两地三中心异地活跃（三个机房之间的网络延迟很小）

3、数据一致性：计算节点失效不会造成数据丢失，存储节点失效会自动选举。 新leader的数据和老leader的数据是强一致的。

C.支付宝的OceanBase

OceanBase的设计思路与Spanner类似，但在SQL、存储、事务等方面有自己的创新。

架构说明：

1、当前版本的计算和存储集中在一个节点（PC、OBServer），单进程程序，进程包括SQL引擎和存储引擎功能。

2、表数据有一个或多个分区（使用分区表），业务需要指定分区规则。 分区是数据迁移和高可用的最小单位。 分区之间的一致性由 MultiPaxos 保证。

3.支持分布式事务，2.x版本支持全局一致的快照。 支持全局一致的备份。

4、兼容MySQL的主要用法和Oracle的标准SQL用法，正在逐步兼容Oracle的更多功能。 比如存储过程、游标和Package等。目标是兼容Oracle的常用功能，让应用去IOE时不修改代码。

5、多租户管理能力，租户灵活扩展，租户之间有一定的资源隔离机制。

6、应用可以通过反向代理obproxy或者ob提供的connector-java访问OceanBase集群。

与Spanner的关系和区别：

1、Spanner大约在2008年开始研发，2012年通过论文公开，首次实现跨地域水平扩展，实现基于普通PC服务器的自动高可用和数据强一致性。 OceanBase从2010年开始研发，同样是在普通PC服务器的基础上rac 启动数据库，开发了自己独有的ACID特性、高可用技术和拆分技术。

2、Spanner对标准SQL的支持不是很好，不是真正的关系型数据库，定位于内部应用。 OceanBase定位为通用的分布式关系数据库，支持标准SQL和关系模型。 基本兼容MySQL功能，逐步兼容Oracle功能。

3. Spanner采用原子钟硬件和TrueTime设计，支持全局一致的快照，提供快照读隔离级别，对节点间网络延迟要求比较高。 OceanBase通过软件提供全球时间服务，实现全球一致的快照功能。

4、缺少Spanner的内部诊断和跟踪机制，而OceanBase的内部诊断和分析机制功能完备，针对商业软件标准。

功能：

1、可扩展性：租户和集群的弹性伸缩非常方便，可以在线完成，对业务写入的影响可控。 可用于两地三中心的异地容灾和多活（单元化设计结合业务）。

2. 可用性：当一个或多个观察者不可用时，只要分区的大部分成员存活，就可以快速选举并恢复服务（RTO=20s）。

3、数据一致性：故障恢复后，数据库数据永不丢失。 RPO=0。