日志留总数、主副本租约咨询

OceanBase 技术问题
#1

image
image1278×421 34.6 KB

image
image905×208 7.2 KB

1、官方文档中日志流总个数，按我第二个截图里的应该是三个吗？日志流换个词理解就是一个复制链路，不知道对不对
2、主副本租约，咋理解？
感谢

#3

@论坛小助手

#4

根据您提供的信息和截图内容，我将分别回答您的两个问题。

1. 日志流总个数及理解

问题分析

  • 您提到“日志流总个数应该是三个吗？”以及“日志流换个词理解就是一个复制链路，不知道对不对”。
  • 根据 OCR 提取的文本内容，“租户的总日志流个数取决于 Primary Zone 和 Locality 的配置。”
  • 结合第二个截图中的 Locality 配置：FULL{1}@zone1, FULL{1}@zone2, FULL{1}@zone3，表示每个 Zone 中有一个 FULL 副本。这表明该租户的日志流副本分布在 3 个 Zone 中，且每个 Zone 中有 1 个 FULL 副本。

文档依据

根据文档片段的信息：

  • 日志流是 OceanBase 数据库自动创建和管理的实体，代表了一批数据的集合，包括若干 Tablet 和有序的 Redo 日志流（参考文档片段 4）。
  • 日志流通过 Paxos 协议实现了多副本日志同步，保证副本间数据的一致性（参考文档片段 4）。
  • 每个日志流的数据在物理上存储多份，每一份叫做日志流的一个副本（参考文档片段 10）。

回答

  1. 日志流总个数

    • 根据您的截图和 OCR 提取的内容，日志流的总个数并不直接等于 3。日志流的个数与租户的分区、表结构、广播日志流等因素有关。而截图中的 Locality 配置仅说明了每个 Zone 中有 1 个 FULL 副本，这意味着每个日志流在 3 个 Zone 中都有一个 FULL 副本。
    • 如果您指的是日志流的副本总数，则为 3（每个 Zone 一个 FULL 副本）。但如果是日志流本身的个数，则需要进一步查看租户内的具体表结构和分区情况。

  2. 日志流的理解

    • 您将日志流理解为“复制链路”是部分正确的。日志流确实涉及数据的复制和同步，但它更准确地描述为一组连续递增的日志数据，记录了数据库中的所有变更操作（参考文档片段 1）。
    • 日志流的主要作用是组织和管理 Redo 日志，支持事务提交、故障恢复、备份归档等功能。

2. 主副本租约的理解

问题分析

  • 您提到“主副本租约，咋理解？”
  • 根据 OCR 提取的文本内容：“日志流的主副本在被选举成为主 (Leader) 后会获得租约 (Lease)，正常工作的主副本在租约有效期内会不停通过选举协议延长租约期。”

文档依据

根据文档片段的信息：

  • 日志流使用改进的 Paxos 协议实现 Redo 日志的持久化和同步（参考文档片段 4）。
  • 主副本在租约有效期内执行主的工作，租约机制保证了数据库异常处理的能力（参考文档片段 10）。

回答

主副本租约的核心概念如下：

  1. 租约的作用

    • 租约是一种时间限制机制，用于确保某个主副本在特定时间内拥有唯一的领导权。只有在租约有效期内，主副本才能执行写入操作。
    • 租约机制避免了多个副本同时成为主副本的情况，从而保证了数据一致性。

  2. 租约的生命周期

    • 当主副本被选举为 Leader 后，它会获得一个租约。
    • 在租约有效期内，主副本会通过选举协议不断延长租约期。
    • 如果主副本所在的服务器出现问题（如宕机），其租约无法得到延续，待租约失效后，其他从副本会通过选举协议选出新的主副本并授予新的租约。

  3. 租约的意义

    • 租约机制是 OceanBase 数据库高可用性和容灾能力的重要组成部分。
    • 它能够自动应对服务器故障，保障数据库服务的持续可用。例如，如果少于半数的从副本所在服务器发生故障，数据库服务仍不受影响；如果主副本所在服务器出现问题，系统会自动选举新的主副本。

总结

  1. 日志流的总个数需要结合租户的具体表结构和分区情况来确定，不能简单地认为是 3。日志流本身是一个逻辑概念，用于组织和管理 Redo 日志。
  2. 主副本租约是一种时间限制机制，用于确保主副本在特定时间内拥有唯一的领导权，避免多主冲突，同时支持自动故障恢复和高可用性。

如果您还有其他疑问，请随时提问！

详情请参考:

  1. 日志流
  2. OceanBase 术语
  3. 副本介绍
  4. 集群架构
  5. 日志归档概述
  6. 备份架构
  7. Redo 日志
  8. 日志流副本概述
#5

优秀啊，想问但没问的也列出来了。我有权限@吗？
回答内容中：

image
image929×208 15.6 KB

服务器宕机，会立马检测出故障，立马在从副本中选举新主吧

#6

会的 ob4.x 8秒内完成选举成功

1 个赞
#7

服务器宕机，会立马检测出故障，立马在从副本中选举新主吧 @论坛小助手

#8

有的 你发帖的时候 把@小助手删除了

#9

根据文档库中的信息，当服务器宕机时，并不会“立马”检测出故障并选举新主，而是需要一定的时间来完成故障检测和选举过程。以下是详细解释：

1. 故障检测时间

  • OceanBase 数据库通过心跳机制检测节点的健康状态。如果某个节点（如 Leader 副本所在的节点）发生宕机，其他节点会通过心跳超时的方式感知到该节点不可用。
  • 心跳超时的时间通常为几秒，具体取决于配置参数和网络环境。

2. 选举新主的时间

  • 当 Leader 副本所在节点被确认宕机后，租约到期，其他从副本会发起无主选举。
  • 根据文档片段 1 的信息，在三副本场景下，新主选举的时间在 30 秒内完成。
  • 在 OceanBase 4.x 版本中，优化了选举机制，通常可以在 8 秒内完成选举（参考您提到的内容）。

3. 总结

  • 服务器宕机后，OceanBase 数据库并不会立即检测出故障并选举新主，而是需要经过以下步骤：
    1. 心跳超时：检测到 Leader 节点不可用（通常几秒）。
    2. 租约到期：等待当前 Leader 的租约过期。
    3. 选举新主：从副本发起无主选举并选出新的 Leader（通常 8 秒内完成）。
  • 因此，整个过程从故障检测到选举完成大约需要 8-30 秒，具体时间取决于版本和配置。

如果您还有其他疑问，请随时提问！

详情请参考:

  1. 高可用 FAQ
  2. 集群管理 FAQ
  3. 分布式选举
  4. 发现磁盘的静默错误
  5. 节点宕机
  6. 重启节点
  7. 数据库应急概述
  8. 少数派节点故障