针对Sharding DB的单点故障,合理构建HA架构

  1. 云栖社区>
  2. 数据和云>
  3. 博客>
  4. 正文

针对Sharding DB的单点故障,合理构建HA架构

知与谁同 2017-07-18 10:42:09 浏览904
展开阅读全文

作者简介

640?wx_fmt=jpeg&tp=webp&wxfrom=5&wx_lazy

何剑敏 

Oracle ACS华南区售后团队,首席技术工程师。多年从事第一线的数据库运维工作,有丰富项目经验、维护经验和调优经验,专注于数据库的整体运维。


sharding database最大的特点是可以横向扩展。但是横向扩展不是RAC的横向扩展,纯sharding db是没有HA架构的。即一个shardcat db,多个shard node db。无论是谁down了,都会造成不可用。我们从上往下捋一下,看看哪里有单点故障,这个单点可以通过什么方式解决。


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

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=

1connection pool


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


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


直接路由

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

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=



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

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=


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


代理路由

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


640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=


所以说,对于直接路由模式,我们有可能出现的问题,是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,那么也是不受到影响的。


3shard node


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


所以,我们要对shard node建立ADG,且启用FSFO。(我会写另外一个文章,介绍如何deploy带ADG的shard node)。如果不用ADG,那么OGG也是另外一种高可用的方案。此外,还有RAC,也避免一个shard node主机挂掉,注意,只是防止主机挂掉,不能防止存储挂掉。如果要防止存储挂掉,还是要建ADG。(这也是为什么sharding的最佳实践,是建立ADG,而RAC方案只是optional)


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


所以,sharding的HA最佳实践,应该是如下的:

640?wx_fmt=png&tp=webp&wxfrom=5&wx_lazy=


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


文章转自数据和云公众号,原文链接

网友评论

登录后评论
0/500
评论
知与谁同
+ 关注
所属云栖号: 数据和云