【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】v6.0.0
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
在CAP理论中，我们TiDB优先保持了CP，就是当网络出现故障时，一个集群可能变成了两个互不通信的小集群，为了保持数据的一致性，只其中一个对外提供服务；那有让两个集群都提供服务的可能性嘛，在不考虑网络恢复后数据的一致性的问题，
【资源配置】
【附件：截图/日志/监控】
PD的Leader只有一个，Leader在哪个集群，哪个集群就对外提供服务。
不过你这一句话让我都凌乱了，如果两个机柜，每个机柜都是3TiDB3PD3TiKV，两个机柜互不相连，这就是两个集群了么？ PD是奇数节点的时候应该就能很好的解释了。
脑洞太大 如果3台机器3副本理论是可以 每台集群可以单独成为集群 也可以变成两套集群 1tkv 一个集群
也有办法方法实现
说错了可以实现1集群变成三集群
背景就不对，网络隔离 1 个集群不会变成两个集群。
所以良好的实践是要求集群只允许有奇数个PD节点，不让有偶数个的情况，网络隔离为2个小集群后有且仅有一个是超过半数的，如果隔离为3个及以上小集群因为pd不超过半数就停止对外服务了
PD有这个个数的硬性限制么？我一直以为是建议奇数，之前出现过项目上1个节点挂掉，只有2个PD节点的情况。不过偶数节点确实有问题，当时出现过频繁切换的情况，都只给自己投票。
实践出真理，可以尝试弄一下，这不是简单的细胞分裂。一个细胞裂开了，两个小细胞都提供完整的作用。总之还是得分情况，分离的两个小集群满足部署一个tidb集群的最小架构，还是有可能实现的，就是可能数据不完整。
不是这个意思，官方没有硬性限制，也只是建议值；只是说我们在部署的时候，注意按照最佳实践来设置，通常可以避免很多问题
我的理解 CP 不就是牺牲一定的可用性，来防止网络故障的分区问题嘛？
开脑洞～ 
准备 分裂 PD 么？ 然后 从3 PD ，2 tidb ，3 tikv 变成两个 1 pd 1 tidb 1 tikv 么？
你说的这是网络分区的情况。
tikv那一侧的3副本的作用就是应对这个问题的啊。
网络分区怎么分也是1边1副本，1边2副本。
其中1副本那边，根本没法提交数据，写的时候没有其他节点的确认，提交不了。2副本那一侧可以正常提交数据。所以只有2副本那一侧能正常提供服务。
假如说1副本那一侧能写入，网络恢复后，根据raft协议，那些都会被回滚。
raft协议就是干这个事儿的。没法实现2边都能提供服务。至少现有的tikv架构是不能的。
如果少数派那边，重新部署一套tiup来管理，配置文件中只包含少数派的节点，这样会不会骗过集群，成功启动？
tikv 本地有个 raft cf，里面记录了region的localstate，记录了每个region有几个副本，peer都是谁，peer对应的storeid是什么。骗不了 
1 个赞
谢谢大佬的提醒；是这样的，目前是想把TiDB部署在跨多个跨域的数据中心上，这种情况下网络出现故障的概率会增大；假设原本的pd节点有七个，可能网络分区后形成了两个小集群，两个集群上的pd节点分别是4和3，那么拥有4个pd节点的集群会对外提供服务；同时拥有3个pd节点的集群会不会有重新选取leader结点的可能，它已经与另外的集群隔离开，是不是重设pd节点总数就可以了
那可以用原来的tiup在少数派这边新增tikv节点，新增regiion的副本数，让少数派这边重新选举嘛， 更新本地的raft cf 嘛
新增的tikv，没有region，就得增加peer，增加peer这个活都是pd下发给leader的tikv。少数派的region都选不出leader，自然就没法接收到pd下发的add peer命令。所以也就增加不了副本。
怼进去的空的tikv也就一直是空的。副本补不了。
上面说的是不改代码的逻辑。改代码的话，一切皆有可能，想怎么实现就怎么实现 
蚯蚓分开两端还能活，哈哈
好的好的，谢谢大佬；我的课题是算力网与TiDB结合，因为算力网由多个数据中心构成，网络影响很大，所以就想实现网络分区后的各分区都能提供服务；然后等待网络恢复后，看看能不能实现数据的最终一致性 
我做过拔网线测试，多数节点哟问题了集群就不可用了，但是网线全部插回去集群由恢复可用