TDSQL简介_原创精品文档.pdfVIP

.

TDSQL(TitanDistributeSQL)—一种分布式数

据库之容灾篇

一、传统的分库分表及由此引入的问题

由于业务数据量巨大以至于无法单表存储，于是，我们习惯了分库分表的方

式。最常用的莫过于按照QQ号的后三位分1000表，除此之外，还有按照大区

分表，按照时间分表，等等。于是我们习惯了下面这样一种SVR与DB交互的

架构结构。

图1—传统的分库分表存储

这个我们习以为常的数据库存储结构，其实包含了一些问题，本篇将主要讨

论主备一致性切换问题，并给出TDSQL主备切换的方式。问题如下：

1、主备的异步同步，在主机宕机的情况下，无法保证数据已经同步到了备

机。

2、人工切换，则对DBA同学的实时处理提出非常高的要求。

;.

.

3、自动切换，可能出现不同SVR对于主DB的健康状态判断不一致，造成

不同SVR把数据写入到不同DB的情况即——脑裂。

4、即使通过仲裁节点来统一调度SVR连向主DB或者备DB，如果流程处

理的不好，也可能因为SVR感知切换的时间差在短时间内造成脑裂。

如何解决上面的问题，业界给出了很多的方案，例如国外有Galera这种通

过协议插件来实现一致性的方案（但这种方案在跨IDC时的性能非常差），国

内也有阿里RDS，TDDL，360的atlas中间件，但上述的方案要么在主备切换

的一致性，要么在主动切换，要么在性能上都会有或多或少的问题，因此我们在

参考上述方案的基础上实现了今天要给大家介绍的方案TitanDistributeSQL

—TDSQL。

二、TDSQL主备切换方案

2.1TDSQL容灾架构

;.

.

图二、TDSQL容灾架构

图二是一个大家熟悉的具备调度能力的分布式集群，下面分别来介绍一个各

个模块的作用及如何互动。

DB——图中的绿色部分，是集群的核心部分，也就是mysql节点。为了实

现主备的强一致性和较高的性能，这里必须使用我们在Mariadb基础上进行二

次开发的MySQL。注意，只有主DB提供写服务，其它DB会被Agent自动设

置成只读。

Agent——监控模块，Agent监控MySQL节点的健康状况，并上报心跳

给Scheduler。

Node——每个MySQL进程和Agent要一起部署，二者组合在一起得到

一个最小的存储控制单元Node。

;.

.

SET——为了实现容灾，通常使用一主N备个节点来组成一个最小的容灾存

储单元，主Node和备Node存储的数据一致，通过后面介绍的强同步来同步

数据。为了实现跨IDC容灾，不同的Node节点需要部署在不同的IDC。

Scheduler——调度模块，Scheduler接收Agent的请求，并判断该DB

是否宕机，如果宕机时间超过阀值，则会触发容灾流程。

Proxy——业务请求分发模块，其实是一