什么是 TiDB 社区版主?
TiDB 社区版主:由TiDB社区中的用户、开发者、Contributor 以及合作伙伴共同组成,并拥有参与对 AskTUG 论坛管理及运营的权限。
关于话题讨论的内容来源?
版主交流群,是由一群热爱 TiDB 的版主、版主候选人及社区活跃小伙伴们组成的一个微信群,我们经常会在群里面交流 TiDB 技术问题,以便于更好地掌握 TiDB 的运维能力,更快速地帮助自己和他人处理 TiDB 问题,获得技术上的提升和成长。
本次话题为 5月26日 在【TiDB 社区技术布道师】群中由 @边城元元 发布的一个问题:社区班版不支持多中心部署吗?随即在【TiDB 社区技术布道师】,后又在版主群中进一步更深层次的讨论,具体的讨论如下:
社区班版不支持多中心部署的理解,是原理上可行,但实际运行效果不好??看 @边城元元 写的两地三中心的文章,原理上是通的
@数据小黑 :
我理解两地三中心的方案,对网络的要求很高,如果实现强一致性,RTO < 30秒,需要延时小于20ms,那需要从机房,网络实施阶段就介入,不是说部署个软件就ok,
所以单从开源软件一侧说实现了两地三中心,有点脱离现实,我理解的问题症结在这
不知道理解的对不对?
理解没问题
任何多中心的,对网络都有极高的要求,RAC MGR都是
想象一下极端的,网络断了怎么办
tidb 两地三中心部署意义不大,multi-raft 导致异地的副本没法恢复 ACID 一致的数据,这个问题还在解决中
所以结论是 原理上可行,实际操作难度比较大
实际操作成本比较高,收效很低,也看怎么定义两地,银行业对两地的要求是 1000km 以上,深圳东莞这种和同城差别不大,成本也低,不用作为两地来看
同城 3 az 还是最适合 tidb 的
业务大的话单元化改造比多中心部署效果要好
异地容灾,用 ticdc / tidb-binlog 拖一个从集群就好了,对网络条件要求也低
raft 对网络要求就高多了,因为 raft 复制是生产端 push 的,leader 给 follower 数据,follower 就要接着,落后太多 leader 就要发 snapshot
ticdc / tidb-binlog 的复制是消费端 pull 的,按需抽取数据,所以对网络要求低
讨论后又引入版主群继续讨论:
@Gin 大佬,这个问题该怎么理解啊,怎么导致的?
首先部署两地三中心,肯定是要打 label 的,目的就是让每个中心存放一份副本
异地灾备中心上的一份副本由很多 region 构成,这些 region 的复制进度是不受限制的。本地两中心故障发生后,把异地作为一个副本整体看待时,各 region 的复制停在了一个参差不齐的位置,是不具备一致性的
收到,这个明白。同城主备模式下,不保证副本能全部收到主中心的数据
这里话题涉及到中心层面来讲的
但是从三中心来讲,如果3副本,每个副本落到一个中心,整个中心挂掉一个,应该不会影响服务吧?
两地三中心,是说一个地方的挂了对吧?那就会有问题了,这个地方要是有俩中心
得整5副本吧
引用:
两地三中心,是说一个地方的挂了对吧?那就会有问题了,这个地方要是有俩中心
是的
从绝对性上讲,就跟副本数无关了,副本数也是慢慢调度的,那就说可能性,如果一个region副本数还未达到这么多,挂了一个tikv也有可能导致不可用
银行构建两地三中心的意义,是同城 rpo=0 的容灾,以及异地有一些 rpo 的容灾
用 multi-raft 做异地容灾,不仅 rpo > 0, ACID 也不满足,ACID 不满足在金融行业是绝对不行的
可以看一下这篇文章的第三章
引用:用 multi-raft 做异地容灾,不仅 rpo > 0, ACID 也不满足,ACID 不满足在金融行业是绝对不行的
本质上还是不能达到调度绝对的均衡,完全理想的状态
这个好像是p社的大佬写的,关于同城主备的方案的思考文章,看观点并不是这个方案可靠,主要是从成本上说,在成本和收益之间做个取舍
@Gin
别怕,同城双中心也有方案: