每个日志流的全功能副本上限为什么是3个？

[宠辱不惊m]

@论坛小助手 是因为3个全功能副本已满足高可用和 RPO=0和 RTO<8s 了吗？

[论坛小助手]

根据文档库中的信息，OceanBase 数据库基于 Paxos 协议实现了多副本容灾方案，提供了少数派故障时 RPO = 0 和 RTO < 8s 的高可用能力（参考文档：高可用概述 → 多副本容灾）。Paxos 协议要求多数派副本同步成功才能提交事务，这意味着在 N 个副本的情况下，至少需要 ⌊N/2⌋ + 1 个副本正常工作才能保证服务的可用性。

关于每个日志流的全功能副本上限为 3 个的原因，可以从以下几点进行分析：

1. 高可用需求
   根据 Paxos 协议，3 个全功能副本可以满足高可用的需求。即使其中一个副本发生故障，剩下的两个副本仍然能够构成多数派（2/3），从而保证服务的连续性和数据一致性。

2. RPO=0 和 RTO<8s 的保障
   在 3 副本架构下，只要不超过半数的副本（即最多允许 1 个副本）发生故障，系统仍然可以通过剩余的副本恢复服务，确保 RPO=0 和 RTO<8s 的目标（参考文档：高可用概述 → 多副本容灾）。

3. 成本与性能的平衡
   虽然理论上可以增加更多全功能副本以提高可用性，但每增加一个副本都会带来额外的存储成本和网络开销。3 副本架构在高可用、性能和成本之间取得了较好的平衡。

4. 扩展性支持
   如果需要更高的可用性，可以通过引入只读型副本（READONLY/R）或列存副本（COLUMNSTORE/C）来扩展读能力，而无需增加全功能副本的数量（参考文档：日志流副本概述 和 日志流和副本概述 → 副本类型）。

综上所述，每个日志流的全功能副本上限为 3 个，主要是因为 3 个全功能副本已经能够满足高可用需求，并且在 RPO=0 和 RTO<8s 的前提下，兼顾了性能和成本的平衡。如果需要进一步提升系统的可用性或扩展读能力，可以通过增加其他类型的副本（如只读型副本或列存副本）来实现。

检索到的文档如下:

1. 日志流副本概述
2. Redo 日志
3. 日志流和副本概述
4. 高可用概述
5. 集群级别的扩容和缩容
6. OceanBase 集群高可用部署方案简介
7. OceanBase 数据库整体架构

[乐1983]

我理解是跟着zone的数量来的吧？

[宠辱不惊m]

不是的，日志流全功能副本上限就是3个，考试题有这道单选题。

[乐1983]

我滴天，那5副本就是说只有3个全功能副本+2个只读副本的存在？

[宠辱不惊m]

也可能是3个全功能副本＋2个仲裁节点

[乐1983]

仲裁节点一般不是只有一个么？哈

[宠辱不惊m]

有文档说只能部署一个仲裁节点吗？我好像没看到