【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】4.1
【问题描述】
假设当前ob集群架构为同城双中心，A中心为主机房3个副本，B中心为备机房2个副本。正常情况下A中心的3个副本多数派即完成了写入。但如果A中心机房整体故障，B中心要如何接管业务？集群副本能降级为3副本吗，这样B中心又满足了多数派继续提供服务？
【复现路径】问题出现前后相关操作
【问题现象及影响】
【附件】
B中心只有2副本，这样集群就挂了，不可以用了。
一般两地三中心五副本才可以解决你说的机房故障。
2个城市，3个机房，第一个城市的2个机房，每个机房2个副本，第二个城市的第三个机房1个副本。这样部署做到机房容灾 。一个机房挂掉，还有3个副本，可以提供服务。
如果要城市容灾就只能三地五中心了。一个城市的机房挂掉，其他2个城市还可以提供服务。
这个跨机房方案就是担心性能啊，同机房性能最好，跨机房如果是交易业务影响会不会比较大？
把主设置到一个机房内，两地三中心五副本的话，四个副本在同城市，网络不会成为瓶颈啊。
三地五中心五副本，城市就有要求的，两个城市在几十公里的距离。上千公里肯定不行
如果只剩两副本应该就变为只读了
1 个赞
两个机房间的网络不确定性太多了，专线抖动一下，业务性能还卡一下吧？
那既要又要，不得有所牺牲吗？
抖动较剧烈肯定是会影响性能，即使主机房是三副本也一样
哈哈，还是感谢解答。建议考虑能不能搞个新特性，副本降级使用，这样B中心机房降级为3副本，已有的2副本就满足多数派了，最后备机房扩容一个节点，最终3副本。
机房内部网络自己维护是可控的。
机房内不能保证机房级故障，不能保证城市级故障啊。
追求机房内收敛，那就部署一个机房。
不能既要又要
1 个赞
企业版好像是有的，但是有很多限制。
社区版我们没有遇到，也没有人支持，不清楚知否支持。
如果是商业版，可以试试主备库
A中心如果整体故障，B中心剩2个副本，能否通过扩容的方式恢复为5个副本，恢复正常运行呢？
应该是要采取特殊手段了
双中心五副本部署架构是有些问题的，建设初期是要避免这种情况，因为真出了问题谁也担不起。
目前只有同城机房，机房级容灾的最佳实践方案是怎样的呢？
社区版的话，4.1.0版本，使用租户级主备同步应该可以实现？
两个机房部署两个集群，租户级进行主备同步，一个机房挂了，主备切换到另一个机房
嗯嗯，这个就跟oracle的adg很相似了，有丢数据风险，哈哈
这个RTO和RPO不太好保证