针对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 条评论
登录 后参与评论

相关文章

来自专栏Golang语言社区

大型服务端开发的反模式技巧

1. 用线程池执行异步任务 ? 为了减少阻塞时间,加快响应速度,把无需返回结果的操作变成异步任务,用线程池来执行,这是提高性能的一种手段。 你可能要惊讶了,这么...

3505
来自专栏影子

给Ionic写一个cordova(PhoneGap)插件

45510
来自专栏程序你好

一个微服务架构的简单示例

2413
来自专栏CSDN技术头条

【问底】许鹏:使用Spark+Cassandra打造高性能数据分析平台(一)

【导读】笔者(许鹏)看Spark源码的时间不长,记笔记的初衷只是为了不至于日后遗忘。在源码阅读的过程中秉持着一种非常简单的思维模式,就是努力去寻找一条贯穿全局的...

2698
来自专栏菩提树下的杨过

Gradle 10分钟上手指南

java的源码构建工具,大致经历了 ant -> maven -> gradle 这个过程,每一次进步,都是在解决之前的工具所带来的问题,简单来说: 1. an...

19710
来自专栏铭毅天下

为什么Elasticsearch查询变得这么慢了?

Elasticsearch社区中经常看到慢查询问题:“你能帮我看看Elasticsearch的响应时间吗?”或者是:“我的ES查询耗时很长,我该怎么做?”

1.5K2
来自专栏美团技术团队

磁盘I/O那些事

背景 计算机硬件性能在过去十年间的发展普遍遵循摩尔定律,通用计算机的CPU主频早已超过3GHz,内存也进入了普及DDR4的时代。然而传统硬盘虽然在存储容量上增长...

74410
来自专栏黑白安全

iOS安全基础之钥匙串与哈希

本文最初是由Chris Lowe编写的,后来经过Ryan Ackermann(ios系统开发者)的修改,已经可以针对最新的Xcode 9.2,Swift 4,i...

962
来自专栏张善友的专栏

MongoDB核心贡献者:不是MongoDB不行,而是你不懂!

近期MongoDB在Hack News上是频繁中枪。许多人更是声称恨上了MongoDB,David mytton就在他的博客中揭露了MongoDB许多现存问题。...

21710
来自专栏北京马哥教育

《大型网站技术架构》读书笔记之六:永无止境之网站的伸缩性架构

一、网站架构的伸缩性设计 01、不同功能进行物理分离实现伸缩 (1)纵向分离:将业务处理流程上得不同部分分离部署,实现系统的伸缩性; ? (2)横向分离:将不同...

3339

扫码关注云+社区