Oracle Sharding DB的高可用架构

sharding database最大的特点是可以横向扩展。但是横向扩展不是RAC的横向扩展，纯sharding db是没有HA架构的。即一个shardcat db，多个shard node db。无论是谁down了，都会造成不可用。

我们从上往下捋一下，看看哪里有单点故障，这个单点可以通过什么方式解决，

我们知道，sharding的架构大致如下，

(1). 从应用端发起之后，往下是connection pool，这个connection pool，指的是Oracle Integrated connections pools (UCP, OCI, ODP.NET, JDBC)。这个connection pool，不在本文的讨论范围内，这个是涉及到中间件的高可用问题。

(2). 往下是shard director(gsm)和shardcat数据库。这涉及到一个路由的分类。直接路由（direct route）还是代理路由（proxy route）

(2.1). 直接路由是基于sharding key，在connection pool中的connect阶段就实现了。如果在connection pool（以下以UCP为例）有缓存，缓存着sharding key的range，和shard以及chunk的mapping关系，所以直接忽略shard director，直接到某个shard，node；

如果在UCP中没有缓存，则到shard director中找一次，再去shard node。且下一次执行的时候，由于已经缓存，就不再需要去shard director中找了。

在直接路由模式下，当连接请求是包含sharding key的，即UCP的连接可以使用sharding相关的API，如pds.createShardingKeyBuilder() 和pds.createConnectionBuilder() ，相关的操作就直接去对应的数据库分片了。

(2.2). 代理路由模式是不基于sharding key的访问，或者是需要查询multi shard的数据，那就需要coordinator database，也就是shardcat数据库。应用就需要通过shardcat数据库，才能找到对应的shard node。

所以说，对于直接路由模式，我们有可能出现的问题，是shard director进程挂了。对于这个问题的解决，我们可以设置多个shard director，每个region最多可以设置5个shard director。shard director的功能，类似于向listener，你可以认为它是一个region listener。接受来自某一个区域的连接，然后进行路由。

对于代理模式，我们需要经过shardcat数据库，那么就可以使用到shardcat数据库的高可用方案了。如ADG，如RAC。在sharding的高可用方案中，我们是优先考虑ADG，再考虑RAC。

另外在提一下，由于如果不是multi shard的查询，就不经过shardcat数据库，所以如果shardcat down了，但是如果只有某个分片的transaction，那么也是不受到影响的。

(3). 再往下，就是shard node了，每个shard node包含分片数据，当一个shard node挂掉的时候，shard table的其他分片，即使是活的，也是无法查询这个shard table。

所以，我们要对shard node建立ADG，且启用FSFO。（我会写另外一个文章，介绍如何deploy带ADG的shard node）。如果不用ADG，那么OGG也是另外一种高可用的方案。此外，还有RAC(update 2016-11-15：关于RAC是否支持，建议大家能正式版出来的时候，试一试，因为之前beta1版的时候，我看到shard node是不支持ASM的，只支持文件系统，但是到目前发布的在线文档，已经没有这个限制了。)，也避免一个shard node主机挂掉，注意，只是防止主机挂掉，不能防止存储挂掉。如果要防止存储挂掉，还是要建ADG。（这也是为什么sharding的最佳实践，是建立ADG，而RAC方案只是optional）

但是由于ADG的FSFO切换影响较大，因此最好的方式，还是RAC+ADG，即如果一个shard node的一个机器挂了，那么在RAC架构下，还有另外一台机器能顶住，不会有问题。如果2个节点都挂了，才FSFO切换到standby。

所以，sharding的HA最佳实践，应该是如下的：

有2个区域（region），每个region有2个或以上的gsm（shard director），然后shardcat数据库有ADG（可以再加RAC），后面的shard node也是要做ADG+FSFO（可以在加RAC）。

原文出处：

https://oracleblog.org/study-note/ha-solution-about-sharding/

我的理解：

Oracle Shard DB的架构和MongoDB基本上是类似的。

附上我写的MongoDB分片集群部署的链接http://blog.csdn.net/chenhaifeng2016/article/details/60139388

Shard Director (GSM)相当于MongoDB的路由服务。

Shard Catalog相当于MongoDB的配置服务。

Shard DB Node相当于MongoDB Mongod节点。

Oracle Sharding DB的高可用架构相关推荐

数据库高可用架构(MySQL、Oracle、MongoDB、Redis)
一.MySQL MySQL小型高可用架构方案:MySQL双主.主从 + Keepalived主从自动切换服务器资源:两台PC Server 优点:架构简单,节省资源缺点:无法线性扩展,主从失败之 ...
MySQL 高可用架构在业务层面的应用分析
MySQL 高可用架构在业务层面的应用分析 http://mp.weixin.qq.com/s?__biz=MzAxNjAzMTQyMA==&mid=208312443&idx=1&a ...
《MySQL性能优化和高可用架构实践》阅读总结
文章目录介绍第1章 MySQL架构介绍 1.1 MySQL简介 1.2 MySQL主流的分支版本 1.3 MySQL存储引擎 1.4 MySQL逻辑架构 1.5 MySQL物理文件体系结构第2章 ...
云原生时代微服务的高可用架构设计
简介: 在8月20日"阿里巴巴技术质量精品课"上,来自蚂蚁的经国分享了对云原生时代微服务的高可用架构设计的全面解析,为大家介绍了应用架构演进路径.云原生时代的技术福利.高可用架构的 ...
蚂蚁金服资深技术专家经国：云原生时代微服务的高可用架构设计
经国蚂蚁金服数字金融线担任技术风险架构师读完需要 15 分钟速读仅需 5 分钟经国,蚂蚁金服资深技术专家,毕业于浙江大学. 2014 年加入蚂蚁金服,先后负责过支付宝的单元化.弹性.去 ORA ...
单表60亿记录等大数据场景的MySQL优化和运维之道 | 高可用架构
015-08-09 杨尚刚高可用架构此文是根据杨尚刚在[QCON高可用架构群]中,针对MySQL在单表海量记录等场景下,业界广泛关注的MySQL问题的经验分享整理而成,转发请注明出处. 杨尚刚,美 ...
高可用架构的设计方法
概述高可用(High Availability),简称HA,是衡量IT系统服务质量的一个极其重要的参考,高可用一直是IT系统设计中需要重点关注的点.本文总结高可用架构中的一些关键设计思想. 衡量指标 ...
雪球在股市风暴下的高可用架构改造分享
本文根据唐福林老师在"高可用架构"微信群所做的<股市风暴下的雪球架构改造经验分享>整理而成,转发请注明来自微信公众号ArchNotes. 唐福林,雪球首席架构师,负责雪 ...
VIPKID 的高可用架构设计及 TiDB 应用实践
原文来源: https://tidb.net/blog/6171efe3 作者:郝海民,许超.本文系 2019 年 11 月北京 TUG 线下活动" 高可用架构设计与实践 "分享实 ...

Oracle Sharding DB的高可用架构

Oracle Sharding DB的高可用架构相关推荐

最新文章

热门文章