什么是 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
别怕，同城双中心也有方案：