关于创建单副本租户的问题咨询

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】4.3.5
【问题描述】
1、单副本租户日志流数量是根据什么计算生成的
2、单副本租户是否不具备高可用
【复现路径】
资源池创建：

image
image1518×296 22.9 KB

租户创建：
image
image1820×656 54.3 KB

可以看出租户在创建的时候没有指定primary zone 查询视图默认是random
查询日志流数量和分布：
image
image1827×471 36.3 KB

从日志流的数量看是一共生成了2个日志流，都是leader。
新版V4培训材料里关于日志流数量的描述：
image
image1261×708 92.5 KB

还请老师辛苦给科普一下

1 个赞
#3
  1. OB 跟其他关系数据库一样，事务除了写数据文件外还要单独写一份事务日志 （write ahead logging 思想） 。这份事务日志要落本地盘才会生效。OB 单副本的时候也是这样。单副本的时候本机肯定是主副本。
  2. 当 OB 用分布式架构部署时（有多副本了），上面那份事务日志还要在其他 备副本（新增的副本肯定是备副本） 落盘。一般是三副本。OB 多副本日志传输应用的投票协议是 MultiPaxos，只要三副本中半数以上成员收到日志并落盘成功，事务就有效。少数派副本最终也必须成功，只是微观层面晚一点而已。
  3. 当 OB 分布式部署的时候比传统主备多了一个新的可能性就是 OB 租户 在每个节点上并不是单纯的读写或只读，而是可以交叉分布，这就是说主备的粒度不再是实例层面，而是比实例层面更小的数据层面。在 V4 以前的版本，这个粒度是分区，分区是比表更细的粒度。好处是 OB 的三节点都可以提供读写服务，并且负载均衡的调配粒度很细 可以很精细的控制各个节点的负载做到尽可能读写均衡或者容量均衡（是尽可能）。此外这个负载均衡通常是自动的，手动运维会非常累，因为粒度太细分区太多。
  4. 粒度太细也有缺陷，就是事务日志同步传输比较耗 CPU和内存资源，可能还有别的缺陷。总体上来说这个导致 OB V1/V2/V3 版本时单机部署对资源需求很大，单机性价比不高。 OBV4 重构了这一块设计。重构的思想简单描述就是将粒度又变粗一些，但是还是比租户实例层面更细。这时候的粒度是一批表。至于是哪一批表是OB自动调度的。OB 如果设置primary_zone(云上叫主可用区）为单zone，则这个粒度是租户所有业务表。 OB 为了管理方便把租户中的元数据表单独抽出来，这个粒度也叫 日志流。你把日志流理解为多副本的日志同步流 可能就好懂了。 所以 每个租户至少看到两个日志流，ls_id 分别为1和1001。如果没有业务表应该就没有 1001 的日志流。单副本OB 租户也有两个日志流就是这个道理。
  5. 当 primary_zone 设置为多个 zone 时，业务数据表的多副本同步流拆分为多个日志流。每个日志流的同步方向不一样，或者说每个日志流的主副本的节点不一样。在同一个同步方向上，没有两个业务日志流，因为没有必要（假设有，为何不合并处理呢）。
    这里可能有个问题到底哪些表归属哪个日志流，这个问题在 OB 里没有意义。让OB 去决定，不用试图去理解，因为干预不了，干脆就不要干预了。表分组技术可以稍微干预一点，确保在同一个表分组里的分区在同一个日志流里。表分组的高级用法也挺复杂的，都是业务决定的。
  6. 多副本同步流还会有一些特殊的场景。比如说复制表，复制表的同步协议是全同步，不是多数派同步。所以复制表的同步流必须单独出来。当你有复制表时，租户里就会额外有个独立的日志流。多个复制表有可能共用一个独立的日志流。
  7. 高可用意思是主副本挂了，有个备副本能顶上。所以有多副本才有高可用。单副本就没有高可用。
2 个赞
#4

感谢老师，那就理解了，培训材料的日志流描述应该指的是业务表，不算1号日志流，感谢

#5

@论坛小助手

#6

根据您提供的信息和文档库中的内容，我将针对您的问题进行详细解答。

1. 单副本租户日志流数量的计算生成

根据您提供的 SQL 查询结果和 OCR 提取的内容，创建单副本租户时，默认情况下会生成多个日志流。具体到您的情况：

  • 资源池创建：您创建了一个资源池 pool_1，指定了 unit_num = 1 和 zone_list = ('zone1', 'zone2', 'zone3')。
  • 租户创建：您创建了一个租户 t1，并且没有指定 primary_zone，默认为 RANDOM。

在查询视图 CDB_OB_LS 和 CDB_OB_LS_LOCATIONS 后，您发现有两个日志流，并且它们都是 LEADER 副本。这表明在创建租户时，系统自动为您分配了两个日志流。

日志流数量的计算逻辑

根据文档片段和您的描述，日志流的数量与以下几个因素有关：

  • 资源池配置：资源池中定义的 UNIT_NUM 和 ZONE_LIST。
  • 租户配置：租户创建时指定的 PRIMARY_ZONE（如果未指定，则默认为 RANDOM）。

具体来说，日志流的数量通常是基于资源池中的 UNIT_NUM 和 ZONE_LIST 来决定的。每个 Zone 中的 Unit 数量会影响日志流的数量。例如，如果您有 3 个 Zone，每个 Zone 中有 1 个 Unit，那么理论上可能会生成 3 个日志流。但在实际操作中，OceanBase 数据库会根据负载均衡机制动态调整日志流的数量和分布。

2. 单副本租户是否具备高可用性

关于单副本租户的高可用性，根据文档片段和您的描述，单副本租户确实不具备高可用性。原因如下：

  • 单副本租户：单副本租户只有一个副本，这意味着如果该副本所在的服务器或节点发生故障，数据将不可用，无法实现自动故障转移和恢复。
  • 多副本租户：相比之下，多副本租户可以通过多个副本分布在不同的 Zone 中，确保在一个副本失效时，其他副本可以继续提供服务，从而实现高可用性。

因此，单副本租户在设计上并不具备高可用性。为了提高系统的可靠性和可用性，建议使用多副本租户。

总结

  1. 日志流数量的计算：日志流的数量主要取决于资源池中的 UNIT_NUM 和 ZONE_LIST 配置，以及租户创建时的 PRIMARY_ZONE 设置。在您的案例中，虽然创建的是单副本租户，但系统可能根据负载均衡机制生成了两个日志流。

  2. 高可用性：单副本租户不具备高可用性，因为它只有一个副本，无法在故障时自动切换。为了实现高可用性，建议使用多副本租户。

如果您有更多问题或需要进一步的帮助，请随时联系 OceanBase 的技术支持团队。希望这些信息对您有所帮助！

检索到的文档如下:

  1. 减少副本
  2. 增加副本
  3. 副本类型转换
  4. 副本迁移
  5. ADD REPLICA
  6. 修改日志流的法定成员数
  7. 创建备租户前准备
  8. 租户介绍
  9. 副本介绍
#7

老师 我再确认一下 是不是1号日志流不是业务表用的

#8

1号日志流是给metadb租户使用的

#9

了解 谢谢

#10

版主和助手介绍内容,学习了