之前的回答结论也有问题，不管集群规模多大，都只能坏1个tikv，坏2个就是不可用的。必须人工介入了。
上面这个文章总计的挺好的。
因为背后 有个 raft , 如果 出现 偶数点, 选举 leader 极端情况下 会出现平票, 然后重新random elect time, 还有一个问题就是, prevote 这样的优化,也很难做.
内涵了业届典型的数据分布方式, 例如TiDB, Oceanbase, 是玩具级项目。 这个有点搞笑了，如果仅在大集群高可用方面来讲目前TiDB是不如polardb这种业务可用性强，但是说OB就有点扯了。
1、在TiDB中默认3副本情况下挂掉任意2节点可能存在他说这种业务可用性降低情况，这点确实不如他讲的有一个组的概念可以减少风险。但是TiDB可以通过设置故障域来降低这种风险，比如三个副本分别放在三个故障域中，任意一个故障域中节点全部挂掉都不会影响集群运行，这也是大大减少业务可用性的风险，如果配置placement rule也更能降低这块的风险（但是目前placement rule配置起来还是较复杂，理想情况下polarDB这种是更优的）。
2、Oceanbase 4.0 一个租户的一个unit（可以理解为一个数据库分片），对应2个副本unit都在其它observer上，这种paxos是unit级别的，这种架构高可用能力是大规模集群的N个节点，只要任意2个挂掉的节点不是同一个paxos组中的（可以理解为传统数据库中单分片高可用是1主2备，三副本，只要别同时挂3个副本）那么整体是没有问题的。这种高可用能力和polardb是相当的，但是polardb的paxos级别是partition级别的，一个数据库中N个partition，要维护非常多的paxos心跳，当一个节点挂了那么必然会影响一部分业务，但是OB这种如果挂掉的是一个副本unit，那么对业务没有影响，而且就算主unit挂了，那么因为并不需要维持那么多的paxos心跳和选举，对系统压力不大，很短时间内就会切换（看他们官宣8秒内全部完成）。
3、高可用能力最好的是单元化，这就和数据库没什么关系了，全部都解耦，高可用最强。其次是是传统分库分表模式，再次是OB这种，其次是polarDB，最后是TiDB这种。但是TiDB还是可以通过调整部署策略提高可用性的，尤其是云化（或者虚拟化）情况下，底层共享存储本就有保护，一个节点挂掉会很快在其它宿主机上被拉起。
1 个赞
这个回复是最贴近问题本质的答案.
同意部分观点.
按个回复一下:
- TiDB的placement rule 跟polardb 里的 "group"概念类似, 也起到类似效果. 物理机布署上勉强能用, k8s上完全不可用.
- oceanbase 4.0 unit特性, 从集群可用性角度, 非常好. 但是, 我从官方文档没看到相关介绍, 需要再看一看.
- 云化, 我想对TiDB还很遥远, 虚拟存储层再加上N倍成本. Polardb, OB这两个不清楚.
TiDB其实主打公有云，因为那是他们的战略方向和盈利点，TiDB一直身在云中，只是我们自己用还比较遥远。我们这边虚拟机场景不少，基本也是按照故障域方式划分，对于TiDB，多个虚拟化集群划分在3个故障域中增强可用性。
重点研究下他们的单级分布式一体化，这个改造主要就是日志流的改造，将partition级别的paxos提升到unit级别，同时不影响partition的调度。
tikv太多确实影响性能，PD收集心跳数据都容易网络堵塞
虽然 PolarDB-X 有明显的贬低他人，吹捧自己的感觉，但是他说的问题确实是一个很严肃，甚至是很严重的问题。我理解的将分片充分打散有利于提高性能和易管理性，将分片固定在一个组里可能导致组和组之间不均衡。假定一个每节点2T的数据库，在节点超过50个tikv的集群数据库中， 只要同时挂两台或者更多机器，几乎一定会有一部分数据不可用或者丢失。 这种结论对数据要求即使故障也不能丢失的行业是不可接受的。因为实际上同时挂两个节点的可能性还是非常可能存在的，虽然TiDB可以通过label设置将节点区分不同机房，不同zone，不同机架。这样可以减少两个机器同时挂掉的可能性，但是仍然不能推翻那个可怕的结论 只要同时挂两台或者更多机器，几乎一定会有一部分数据不可用或者丢失。。 哪怕是同一个机房同时挂掉两个机器的可能性仍然是有的，比如在机房空调故障时，多个机器可能因为过热同时重启，维护人员误操作可能导致一整个机柜或者一整排机柜被断电，网络交换机可能同时故障导致所有连到这两个交换机的所有机器都不能连接。虽然这类操作在非常规范的机房是很难发生的，但是在不那么规范的机房是很有可能出现的。我建议TiDB开发人员充分考虑这种风险。
如果数据真的很重要可以考虑5副本
五副本我理解不能解决根本问题，我们假设一个三副本的，每节点2T数据共有50个节点，纯数据库容量约33T的数据库，一个节点的Region数量将达到2,000,000M/100M=20000个。
按他们推理的模型计算
当每个节点达到50个Region的时候，同时挂两个机器出现至少一个Region数据不可用或者丢失的概率已经高达90%.
当Region 数量达到2万个的时候，概率可能就是99.99%了。
哪怕换成5副本，也是从同时挂两个节点到同时挂3个节点的事情，差别只在小数点不能解决根本问题。
这真的是令人担心的事情. 不要说不会同时挂两个节点，我知道的这种事情很多，比如某头部非银金融机构，交易时间点维护电源导致核心交易系统数据库主备机同时宕机。。案例太多了
坏2个数据分片不特殊处理肯定不会提供服务了，但这数据丢失概率咋算的？照这算法没有能用于生产的了。 不知道polardb x 同一套dn下坏2个概率多大，只剩最后一个后还能不能提供服务？从架构看polardbx同时坏两个的概率相比tidb这样分布式导致不可用的概率确实低，但polardbx现在的架构是由于分库分表的历史无奈选择还是确实考虑可用后的正确选择？
这里计算是应该按服务器个数或者tikv个数计算，而不是region的数量
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。