分布式数据库容灾容错方案？

分布式数据库的“切换”概念与传统数据库不太一样。
分布式数据库的“切换”包含两层意思：
第一层是主从副本的切换，这部分工作可以由集群根据一致性协议自动选举leader后实现，无需进行人工干预，完全自动进行；当然，也可以手工进行切换。
第二层是主备集群的切换，这种与传统数据库更加类似，前提是要准备一套灾备集群。

分布式数据库生产集群采用两地三中心五副本架构，同城生产机房2副本、同城灾备机房2副本、异地灾备机房1副本，根据一致性协议以及“大多数”原则，必须保证有3副本存活才能维持数据库正常服务。为了保证数据库写服务效率，异地机房的1副本仅作为从副本，因此无leader，所有的leader都分布在同城两个机房里。
如果异地机房出故障，那么集群剩下4副本，此时写操作请求发生后，只要有3个副本写成功即可，同时，同城两个机房有全部leader，因此无需重新选举leader，也就不存在主从切换；
如果同城任一机房故障，那么集群剩下3副本 ，此时写操作请求发生后，需要3个副本都写成功才认为成功， 但是由于有1个副本在异地，存在异地延时，影响写效率，因此这种情况要先人工将集群5副本降为3副本，然后由集群在同城另一个正常的机房自动选举出leader，从而实现所谓的“主从切换”。

除了上述场景，在异地灾备机房可以单独准备一套灾备集群，与生产集群进行数据同步，从而实现传统意义上的“灾备”。

高可用方案，各家产品实现有所差异。一般情况下，在同城双中心异地单中心的情况下，当同城某AZ出现问题时，是无法自动切换到同城第二个AZ，是需要引入第三个AZ，满足仲裁需求的。当然有些是可以写死切换逻辑在里面，但非标准的切换流程。因此，一般建议在同城采用3AZ，满足多数派选举，可实现自动切换能力。异地一般不建议参与其中，毕竟存在较长时延。