【TiDB 社区版主话题探讨】-深入讨论关于两地三中心问题

什么是 TiDB 社区版主?

TiDB 社区版主:由TiDB社区中的用户、开发者、Contributor 以及合作伙伴共同组成,并拥有参与对 AskTUG 论坛管理及运营的权限。

关于话题讨论的内容来源?

版主交流群,是由一群热爱 TiDB 的版主、版主候选人及社区活跃小伙伴们组成的一个微信群,我们经常会在群里面交流 TiDB 技术问题,以便于更好地掌握 TiDB 的运维能力,更快速地帮助自己和他人处理 TiDB 问题,获得技术上的提升和成长。

本次话题为 5月26日 在【TiDB 社区技术布道师】群中由 @边城元元 发布的一个问题:社区班版不支持多中心部署吗?随即在【TiDB 社区技术布道师】,后又在版主群中进一步更深层次的讨论,具体的讨论如下:

@Jellybean :

社区班版不支持多中心部署的理解,是原理上可行,但实际运行效果不好??看 @边城元元 写的两地三中心的文章,原理上是通的

@数据小黑

我理解两地三中心的方案,对网络的要求很高,如果实现强一致性,RTO < 30秒,需要延时小于20ms,那需要从机房,网络实施阶段就介入,不是说部署个软件就ok,

所以单从开源软件一侧说实现了两地三中心,有点脱离现实,我理解的问题症结在这

不知道理解的对不对?

@小明SQLBOY

理解没问题

@xuexiaogang

任何多中心的,对网络都有极高的要求,RAC MGR都是
想象一下极端的,网络断了怎么办

@Gin

tidb 两地三中心部署意义不大,multi-raft 导致异地的副本没法恢复 ACID 一致的数据,这个问题还在解决中

@Jellybean :

所以结论是 原理上可行,实际操作难度比较大

@Gin

实际操作成本比较高,收效很低,也看怎么定义两地,银行业对两地的要求是 1000km 以上,深圳东莞这种和同城差别不大,成本也低,不用作为两地来看

同城 3 az 还是最适合 tidb 的

@jiashiwen

业务大的话单元化改造比多中心部署效果要好

@Gin

异地容灾,用 ticdc / tidb-binlog 拖一个从集群就好了,对网络条件要求也低
raft 对网络要求就高多了,因为 raft 复制是生产端 push 的,leader 给 follower 数据,follower 就要接着,落后太多 leader 就要发 snapshot
ticdc / tidb-binlog 的复制是消费端 pull 的,按需抽取数据,所以对网络要求低

讨论后又引入版主群继续讨论:

@jiyf

@Gin 大佬,这个问题该怎么理解啊,怎么导致的?

@Gin

首先部署两地三中心,肯定是要打 label 的,目的就是让每个中心存放一份副本

异地灾备中心上的一份副本由很多 region 构成,这些 region 的复制进度是不受限制的。本地两中心故障发生后,把异地作为一个副本整体看待时,各 region 的复制停在了一个参差不齐的位置,是不具备一致性的

@jiyf

收到,这个明白。同城主备模式下,不保证副本能全部收到主中心的数据

这里话题涉及到中心层面来讲的

但是从三中心来讲,如果3副本,每个副本落到一个中心,整个中心挂掉一个,应该不会影响服务吧?

两地三中心,是说一个地方的挂了对吧?那就会有问题了,这个地方要是有俩中心

@h5n1

得整5副本吧

@Gin

引用:
两地三中心,是说一个地方的挂了对吧?那就会有问题了,这个地方要是有俩中心

是的

@jiyf

从绝对性上讲,就跟副本数无关了,副本数也是慢慢调度的,那就说可能性,如果一个region副本数还未达到这么多,挂了一个tikv也有可能导致不可用

@Gin

银行构建两地三中心的意义,是同城 rpo=0 的容灾,以及异地有一些 rpo 的容灾
用 multi-raft 做异地容灾,不仅 rpo > 0, ACID 也不满足,ACID 不满足在金融行业是绝对不行的
可以看一下这篇文章的第三章

@jiyf

引用:用 multi-raft 做异地容灾,不仅 rpo > 0, ACID 也不满足,ACID 不满足在金融行业是绝对不行的

本质上还是不能达到调度绝对的均衡,完全理想的状态

这个好像是p社的大佬写的,关于同城主备的方案的思考文章,看观点并不是这个方案可靠,主要是从成本上说,在成本和收益之间做个取舍

@Gin
别怕,同城双中心也有方案:

2 个赞

不行就整三地三中心哈哈

个人见解,这里应该先划清两个概念:
1、两地三中心一般是指同城双活+异地的灾备架构;
2、这个帖子谈论的是tidb两地三副本的概念;

同城双活是通过专线实现实时同步的,而异地灾备一般是异步的。

如果一个tidb集群多个副本放在两地,其中异地节点肯定会有延迟,而 raft 算法是保证数据在多数节点安全落地,那么就会出现一个情况,本地的两个中心(副本)一直是最新的,而异地中心(副本)一直是落后的,即存于异地的副本是不可用状态,这时如果同城的两个数据中心都没了,那么异地的数据其实也是不可用的。

所以tidb要做两地三中心,还是应该同城一套集群,异地一套集群,两套集群通过 ticdc 同步数据,这样才能真正起到异地容灾的效果。

1 个赞

TiCDC是异步的,一样没办法保证RPO

ticdc或br 可以做备份用。
有时延

明年就要遭遇这样的场景了~

1)如果异地的数据中心 数据追不上,那么即使使用ticdc同步到异地也会有问题吧。这个时候的ticdc只能写入本地的kafka或集群才能有效吧。

2)如果异地一直追不上 。
那么 3中心的 第三个中心就没有意义。

3)两地3中心的 ,异地的中心,如果做为延时的备份或 非实时灾备还有有效的。

两地三中心的异地灾备中心本来就是做异步同步的

所以这里讨论的核心在于,同城两个中心都挂了的情况下,异地中心是无法保证ACID和RPO的,因此两地三中心的那个异地中心暂时还是个伪命题

在实际的生产过程中需要保证 1.公司特别有钱 2. 公司核心业务 这两个满足了在来谈多中心. 从软件架构来说 ,越复杂意味着越难维护, 考验整个运维团队. 个人人为公司不到一定体量别谈这些 ,有一定体量的公司 不缺相应的技术专家 . 换句话说 ,命题不成立. 有这种需求的公司不缺这点钱 还要用社区版

1 个赞