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

作者简介

何剑敏

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

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

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

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;

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

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

代理路由

代理路由模式是不基于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,那么也是不受到影响的。

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最佳实践,应该是如下的:

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

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2016-11-16

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏云数据库

【译文】Amazon Aurora:云时代的数据库

Aurora是AWS服务的一部分,为OLTP业务提供关系型数据库服务。本文介绍了Aurora的系统架构以及背后设计上的考虑。我们认为,高吞吐量数据处理的核心问题...

3167
来自专栏Java技术

Redis 深度历险:核心原理与应用实践!

Redis 是如今互联网技术架构中,使用最广泛的缓存。支持复杂的数据结构,支持持久化,支持主从集群,支持高可用,支持较大的value存储...

1611
来自专栏Java3y

外行人都能看懂的SpringCloud,错过了血亏!

认识我的朋友可能都知道我这阵子去实习啦,去的公司说是用SpringCloud(但我觉得使用的力度并不大啊~~)…

781
来自专栏无题

TPS与QPS概念

QPS是一种特殊的TPS,TPS指的是服务器每秒处理事务数,而QPS是针对查询服务器的每秒事务处理数也即每秒查询数 一、TPS:Transactions Pe...

4006
来自专栏后端技术探索

电商平台搞秒杀背后的技术实现

每当电子商务平台搞活动,“秒杀”经常是提升网站活跃度的利器之一。比如活动日早上10点1元爱疯7秒杀7台,谁看到了估计都想去秒一把,万一秒中了呢。秒杀的典型特征就...

753
来自专栏刘迪的专栏

Redis 经典案例分析:消失的连接

在Redis 经典案例分析这一专题中,我将与大家一起学习关于 Redis 维护的相关内容,把真是业务环境中遇到的维护问题与大家分享,共同积累 Redis 维护的...

7240
来自专栏Java技术

Kafka简介、基本原理、执行流程与使用场景

Apache Kafka是分布式发布-订阅消息系统,在 kafka官网上对 kafka 的定义:一个分布式发布-订阅消息传递系统。 它最初由LinkedIn公司...

622
来自专栏BeJavaGod

分布式系统的那些事儿(四) - MQ时代的通信

之前在讲RPC通信的各种好处,特别好用,但是RPC并不是万能的,也并不是适用于各种场景的,因为他是同步的;现如今很多场景下的调用都是异步的,系统A调用B后,并不...

3144
来自专栏ThoughtWorks

TW洞见〡Ruby Web服务器:这十五年

文章作者来自:ThoughtWorks - 韩翼。 坦率的说,作为一门年轻的计算机语言,Ruby在最近二十年里的发展并不算慢。但如果与坐拥豪门的明星语言们相比,...

27310
来自专栏北京马哥教育

LinkedIn —— Apache Kafka 的伸缩扩展能力

什么是Kafka? Apache Kafka是一个演进的发布/订阅消息系统。系统结合队列和消息机制,可把它当成在一群服务器间进行的日志提交过程。消息被分成...

2764

扫码关注云+社区