频繁出现OBServer 非预期的内部错误

OceanBase 技术问题
,
#12

对于重放出现内部错误的日志，集群会自动进行重放吗？或者会自动处理这个重放延时吗？@论坛小助手

#13

根据文档库中的信息，可以对重放出现内部错误的日志是否会被集群自动重放或自动处理延时进行分析。

日志重放的机制

日志重放的基本原理

在 OceanBase 数据库中，副本通过回放 Redo 日志来保持与 Leader 副本的数据一致性。当某个分区的 Leader 所在机器发生故障或负载过高无法提供服务时，系统会重新选举一个新 Leader。新 Leader 会继续执行未完成的事务，并通过回放日志确保数据一致性。

参考文档: [Redo 日志 → 日志的容灾](片段标题: Redo 日志 → 日志的容灾)

说明: 只要多数派副本仍然可用，OceanBase 数据库可以通过日志重放机制恢复数据并继续提供服务。

日志重放失败后的处理机制

自动重放

如果日志重放在过程中出现内部错误（如您提到的 errcode=-4388 和 errcode=-4389），OceanBase 数据库会尝试自动重放失败的日志。这种机制确保即使在某些情况下日志重放失败，系统仍能通过多次尝试恢复数据一致性。

参考文档: [Redo 日志 → 日志的容灾](片段标题: Redo 日志 → 日志的容灾)

说明: 当某个副本因日志重放失败而落后于其他副本时，OceanBase 数据库会将其标记为不可用，并由其他健康副本接管其职责。待该副本恢复正常后，它会重新从 Leader 副本拉取并重放缺失的日志。

自动处理重放延时

对于日志重放延迟的问题，OceanBase 数据库提供了以下机制来自动处理：

  1. 调整日志重放任务优先级

OceanBase 数据库会动态调整日志重放任务的优先级，确保关键任务能够优先完成。例如，在高负载场景下，系统可能会降低非关键任务的优先级以保证核心功能的正常运行。

  1. 自动降级机制

在企业版中，如果半数以上副本发生故障导致日志同步失败，仲裁服务会自动执行日志流降级流程以恢复服务。虽然社区版不支持仲裁服务功能，但仍然可以通过多数派副本机制确保数据一致性和服务可用性。

参考文档: [修改日志流降级控制时间](片段标题: 修改日志流降级控制时间)

注意: 该内容仅适用于 OceanBase 数据库企业版。OceanBase 数据库社区版暂不支持仲裁服务功能。

总结

对于重放出现内部错误的日志，OceanBase 数据库会尝试自动重放失败的日志，确保数据一致性和服务可用性。
对于重放延迟问题，OceanBase 数据库会通过调整任务优先级和多数派副本机制自动处理。如果您使用的是企业版，还可以通过仲裁服务的自动降级机制进一步提升系统的可用性。
如果问题仍未解决，建议联系 OceanBase 技术支持团队获取进一步帮助。

检索到的文档如下:

  1. 日志归档前准备
  2. Failover
  3. 备份架构
  4. 管理历史统计信息
  5. 自动统计信息收集
  6. 列存 FAQ
  7. 日志稳定性
  8. Redo 日志
  9. ls_gc_delay_time
  10. 修改日志流降级控制时间
#14

可以详细讲解一下回放 Redo 日志的详细过程吗？ @论坛小助手

#15

根据文档库中的信息，可以详细讲解 Redo 日志的回放过程。以下是 Redo 日志回放的详细步骤和机制：

1. Redo 日志的产生

在事务执行过程中，OceanBase 数据库会将所有的数据修改操作记录为 Redo 日志。这些日志以物理日志的形式存储，每条日志的最大大小为 2 MB。在 V3.x 及之后的版本中，当事务内数据超过 2 MB 时，生成 Redo 日志并提交到 Clog 模块。
参考文档: [Redo 日志 → 日志的产生](片段标题: Redo 日志 → 日志的产生)

2. Redo 日志的同步

Leader 副本负责生成 Redo 日志，并通过 Multi-Paxos 协议将日志同步到多数派副本。只有当 Redo 日志被成功写入到多数派副本后，事务才能提交。
参考文档: [Redo 日志 → 概述](片段标题: Redo 日志 → 概述)

3. Redo 日志的接收与存储

Follower 副本接收到 Leader 副本发送的 Redo 日志后，将其持久化到本地磁盘。每个分区的所有日志要求在逻辑上连续有序，日志文件称为 Clog，位于 store/clog/tenant_xxxx 目录下。
参考文档: [Redo 日志 → 日志文件类型](片段标题: Redo 日志 → 日志文件类型)

4. Redo 日志的回放准备

当 Follower 副本接收到 Redo 日志后，会根据 transaction_id 和回调操作链表的索引值进行哈希，分配到当前租户的日志回放线程池的不同任务队列中。这种机制允许不同事务的 Redo 日志并行回放，同时保证了回放的正确性。
参考文档: [Redo 日志 → 日志的回放](片段标题: Redo 日志 → 日志的回放)

5. Redo 日志的回放执行

回放过程分为以下几个步骤：

  • 创建事务上下文：为每个事务创建一个事务上下文，用于跟踪事务的状态和操作历史。
  • 还原操作历史：根据 Redo 日志的内容，在事务上下文中还原出操作历史。
  • 提交事务：当回放到 Commit 日志时，事务提交，相当于在副本上重新执行了一次事务。
    参考文档: [Redo 日志 → 日志的回放](片段标题: Redo 日志 → 日志的回放)

6. 多副本一致性

所有副本都会收到相同的一段 Redo 日志并回放出数据，从而保证了一个成功提交的事务的修改最终会在所有副本上生效并保持一致。这种机制确保了即使某个副本发生故障，系统仍然可以通过其他健康副本恢复数据。
参考文档: [Redo 日志 → 概述](片段标题: Redo 日志 → 概述)

7. 容灾与故障恢复

如果某一分区的 Leader 所在机器发生故障或负载过高无法提供服务时，系统会重新选举一个新的 Leader。新 Leader 会继续执行未完成的事务，并通过回放日志确保数据一致性。
参考文档: [Redo 日志 → 日志的容灾](片段标题: Redo 日志 → 日志的容灾)

总结

Redo 日志的回放过程包括以下几个关键步骤：

  1. 日志的产生：事务执行过程中生成 Redo 日志。
  2. 日志的同步：通过 Multi-Paxos 协议将日志同步到多数派副本。
  3. 日志的接收与存储：Follower 副本接收到日志并持久化到本地磁盘。
  4. 日志的回放准备：根据事务 ID 和回调操作链表索引值进行哈希分配。
  5. 日志的回放执行：创建事务上下文、还原操作历史、提交事务。
  6. 多副本一致性：所有副本回放出相同的数据，确保一致性。
  7. 容灾与故障恢复：通过重新选举 Leader 和日志重放机制恢复服务。

如果您需要更详细的解释或有其他相关问题，请随时联系 OceanBase 技术支持团队获取进一步帮助。

检索到的文档如下:

  1. Redo 日志
  2. OceanBase 数据库整体架构
  3. 备份架构
  4. 副本介绍
#16

这一句不是很清除，在 V3.x 及之后的版本中，所有的事务数据都会提交到 Clog 模块吗？是多个事务共用2MB，写满后发给 Clog 模块还是每个事务单独写一个2MB，不论写满或不写满2MB都会发给Clog 模块呢？ @论坛小助手

#17

根据文档库中的信息，可以对您提到的 Redo 日志生成和提交机制进行详细解答。

关于 Redo 日志生成和提交的机制

在 OceanBase 数据库中，Redo 日志的生成和提交机制在 V3.x 及之后的版本中有所优化。以下是具体的解释：

  1. Redo 日志的生成条件
    在 V3.x 之前的版本中，OceanBase 数据库仅在事务提交时才会将事务上下文中保存的历史操作转换成 Redo 日志，并以 2 MB 为单位提交到 Clog 模块。而在 V3.x 及之后的版本中，新增了即时写日志功能。这意味着当事务内数据超过 2 MB 时，即使事务尚未提交，也会生成 Redo 日志并提交到 Clog 模块。

    参考文档: [Redo 日志 → 日志的产生](片段标题: Redo 日志 → 日志的产生)

  2. Redo 日志的提交方式

    • 单个事务的数据处理
      每个事务的数据会单独生成 Redo 日志。如果某个事务的数据量超过了 2 MB，则会立即生成 Redo 日志并提交到 Clog 模块，而不需要等到事务提交或写满 2 MB 才触发提交。换句话说，每个事务的数据是独立处理的，不会与其他事务共用一个 2 MB 的缓冲区。

    • 未达到 2 MB 的情况
      如果事务的数据量小于 2 MB，则会在事务提交时将所有历史操作转换为 Redo 日志，并一次性提交到 Clog 模块。这种情况下，即使数据量不足 2 MB，也会在事务提交时触发提交操作。

    总结:

    • 如果事务的数据量超过 2 MB，在事务执行过程中会分批生成 Redo 日志并提交到 Clog 模块。
    • 如果事务的数据量小于 2 MB，则在事务提交时一次性生成并提交 Redo 日志。

  3. 多个事务的关系
    多个事务之间互不影响，每个事务都有自己独立的缓冲区和日志生成逻辑。不存在多个事务共用一个 2 MB 缓冲区的情况。

具体回答您的问题

  • “所有的事务数据都会提交到 Clog 模块吗？”
    是的，所有的事务数据最终都会通过 Redo 日志的形式提交到 Clog 模块。无论是事务提交时还是事务执行过程中（数据量超过 2 MB），都会触发 Redo 日志的生成和提交。

  • “是多个事务共用 2 MB，写满后发给 Clog 模块，还是每个事务单独写一个 2 MB，不论写满或不写满 2 MB 都会发给 Clog 模块呢？”
    每个事务单独处理，不存在多个事务共用 2 MB 缓冲区的情况。

    • 如果事务的数据量超过 2 MB，在事务执行过程中会分批生成 Redo 日志并提交到 Clog 模块。
    • 如果事务的数据量小于 2 MB，则在事务提交时一次性生成并提交 Redo 日志。

总结

在 V3.x 及之后的版本中，OceanBase 数据库的 Redo 日志生成和提交机制更加灵活：

  • 每个事务的数据是独立处理的，不存在多个事务共用 2 MB 缓冲区的情况。
  • 如果事务的数据量超过 2 MB，在事务执行过程中会分批生成 Redo 日志并提交到 Clog 模块。
  • 如果事务的数据量小于 2 MB，则在事务提交时一次性生成并提交 Redo 日志。

如果您还有其他疑问，请随时联系 OceanBase 技术支持团队获取进一步帮助。

具体信息可参考以下文档:

  1. Redo 日志
  2. 副本介绍
  3. log_tool
  4. 日志同步问题
  5. OceanBase 数据库整体架构
#18

关于redo日志的回访执行，可以讲解的在详细一些吗？如果能举例就更好了 @论坛小助手

#19

根据文档库中的信息，可以对 Redo 日志的回放执行过程进行更详细的讲解，并通过一个简单的例子来帮助理解。

1. Redo 日志回放的基本原理

Redo 日志的回放是 OceanBase 数据库提供高可用能力的基础。当某个副本接收到 Leader 副本发送的 Redo 日志后，会将这些日志按照一定的规则分配到不同的任务队列中进行并行回放。回放的过程包括以下几个关键步骤：

1.1 创建事务上下文

在回放开始时，系统会为每个事务创建一个事务上下文（Transaction Context）。这个上下文用于跟踪事务的状态和操作历史，确保事务在回放过程中能够正确地还原其修改。

1.2 还原操作历史

根据 Redo 日志的内容，在事务上下文中还原出操作历史。每条 Redo 日志记录了数据库对于数据的全部修改历史，具体的说记录的是一次写操作后的结果。例如，如果某条 Redo 日志记录了一次对表 T 的插入操作 INSERT INTO T (id, value) VALUES (1, 'A')，那么在回放过程中，系统会根据这条日志重新执行该插入操作。

1.3 提交事务

当回放到 Commit 日志时，事务提交。这相当于在副本上重新执行了一次事务的所有操作。提交完成后，副本上的数据状态与 Leader 副本保持一致。

2. 并行回放机制

OceanBase 数据库支持并行回放 Redo 日志，以提高回放速度。具体来说：

  • 不同事务的 Redo 日志可以并行回放：每个事务的 Redo 日志会被分配到不同的任务队列中，由不同的线程并行处理。
  • 同一个事务的不同 Redo 日志也可以并行回放：对于一个事务的多条 Redo 日志，系统会根据其依赖关系进行并行处理，确保回放的正确性。

3. 示例

假设我们有一个简单的事务，包含以下操作：

BEGIN;
INSERT INTO T (id, value) VALUES (1, 'A');
UPDATE T SET value = 'B' WHERE id = 1;
COMMIT;

3.1 生成 Redo 日志

在事务执行过程中，OceanBase 数据库会生成以下 Redo 日志：

  • 插入操作的日志：INSERT INTO T (id, value) VALUES (1, 'A')
  • 更新操作的日志：UPDATE T SET value = 'B' WHERE id = 1
  • 提交操作的日志：COMMIT

3.2 同步 Redo 日志

Leader 副本将这些 Redo 日志通过 Multi-Paxos 协议同步到 Follower 副本。

3.3 回放 Redo 日志

Follower 副本接收到这些 Redo 日志后，开始回放：

  1. 创建事务上下文：为该事务创建一个事务上下文。
  2. 还原操作历史：
    • 根据插入操作的日志，执行 INSERT INTO T (id, value) VALUES (1, 'A')。
    • 根据更新操作的日志，执行 UPDATE T SET value = 'B' WHERE id = 1。
  3. 提交事务：当回放到 Commit 日志时，事务提交，确保副本上的数据状态与 Leader 副本一致。

4. 容灾与故障恢复

如果某一分区的 Leader 所在机器发生故障或负载过高无法提供服务时，系统会重新选举一个新的 Leader。新 Leader 会继续执行未完成的事务，并通过回放日志确保数据一致性。

总结

Redo 日志的回放执行过程包括以下几个关键步骤：

  1. 创建事务上下文：为每个事务创建一个事务上下文。
  2. 还原操作历史：根据 Redo 日志的内容，在事务上下文中还原出操作历史。
  3. 提交事务：当回放到 Commit 日志时，事务提交。

通过并行回放机制，OceanBase 数据库能够高效地处理大量 Redo 日志，确保数据一致性和高可用性。

如果您需要更详细的解释或有其他相关问题，请随时联系 OceanBase 技术支持团队获取进一步帮助。

更多信息请查看:

  1. Redo 日志
  2. oceanbase.DBA_OB_LS
  3. oceanbase.CDB_OB_LS
  4. 恢复流程
#20

leader同步过来的redo日志和副本执行完回放记录的redo日志是同一个日志吗？日志如何区分，redo日志的名称和格式或者内容都是什么 @论坛小助手

#21

根据文档库中的信息，可以详细解答您提到的 Leader 副本同步过来的 Redo 日志与 Follower 副本回放后记录的 Redo 日志的关系，以及 Redo 日志的名称、格式和内容。

1. Leader 同步过来的 Redo 日志与 Follower 回放后记录的 Redo 日志是否相同？

Leader 同步过来的 Redo 日志与 Follower 回放后记录的 Redo 日志是同一个日志。

  • Leader 副本生成 Redo 日志：
    Leader 副本在事务执行过程中生成 Redo 日志，并通过 Multi-Paxos 协议将这些日志同步到 Follower 副本。

  • Follower 副本接收并存储 Redo 日志：
    Follower 副本接收到 Leader 副本发送的 Redo 日志后，会将其持久化到本地磁盘。这个过程确保了即使 Leader 副本发生故障，Follower 副本仍然能够通过已接收到的日志恢复数据。

  • Follower 副本回放 Redo 日志：
    Follower 副本在接收到 Redo 日志后，会对其进行回放以保持与 Leader 副本的数据一致性。回放完成后，Follower 副本上的数据状态与 Leader 副本一致。

因此，Leader 副本同步过来的 Redo 日志与 Follower 副本回放后记录的 Redo 日志是同一个日志，只是在不同的副本上进行了存储和处理。

参考文档: [Redo 日志 → 概述](片段标题: Redo 日志 → 概述)

2. 如何区分 Redo 日志？

Redo 日志的区分主要通过以下几种方式：

  1. 日志文件名：
    OceanBase 数据库的 Redo 日志文件称为 Clog（Commit Log），文件位于 store/clog/tenant_xxxx 目录下（其中，xxxx 表示租户 ID）。文件编号从 0 开始并连续递增，文件 ID 不会复用。

  2. 日志流（Log Stream）：
    每个分区的所有日志要求在逻辑上连续有序，机器上同一租户的所有 Tablet 产生的日志会写入到同一个日志流中。日志流中的日志存在全序关系。

  3. 日志内容标识：
    每条 Redo 日志都包含唯一的标识信息，例如 transaction_id 和回调操作链表的索引值，用于区分不同的事务和操作。

参考文档: [Redo 日志 → 日志文件类型](片段标题: Redo 日志 → 日志文件类型)

3. Redo 日志的名称、格式和内容

3.1 Redo 日志的名称

Redo 日志文件的名称遵循以下规则：

  • 文件路径：store/clog/tenant_xxxx
  • 文件命名：文件编号从 0 开始并连续递增，例如 clog_00000000000000000000.log。

3.2 Redo 日志的格式

Redo 日志是一种物理日志，记录了数据库对于数据的全部修改历史。每条 Redo 日志的最大大小为 2 MB。

3.3 Redo 日志的内容

Redo 日志的内容包括以下几个部分：

  1. 事务标识：
    每条 Redo 日志都包含事务的唯一标识 transaction_id，用于区分不同的事务。

  2. 操作类型：
    记录了具体的数据库操作类型，例如插入（INSERT）、更新（UPDATE）、删除（DELETE）等。

  3. 操作数据：
    记录了操作的具体数据内容，例如插入或更新的字段值。

  4. 元数据：
    包括日志生成的时间戳、日志所属的租户 ID、Tablet ID 等信息。

  5. Commit 标志：
    当事务提交时，会生成一条 Commit 日志，表示该事务的所有操作已完成。

参考文档: [Redo 日志 → 日志的产生](片段标题: Redo 日志 → 日志的产生)

总结

  1. Leader 同步过来的 Redo 日志与 Follower 回放后记录的 Redo 日志是同一个日志。

    • Leader 副本生成 Redo 日志并通过 Multi-Paxos 协议同步到 Follower 副本。
    • Follower 副本接收到日志后进行持久化和回放。

  2. Redo 日志的区分方式：

    • 通过日志文件名（store/clog/tenant_xxxx）。
    • 通过日志流（Log Stream）。
    • 通过日志内容标识（如 transaction_id 和回调操作链表的索引值）。

  3. Redo 日志的名称、格式和内容：

    • 名称：store/clog/tenant_xxxx，文件编号从 0 开始递增。
    • 格式：物理日志，每条日志最大为 2 MB。
    • 内容：包括事务标识、操作类型、操作数据、元数据和 Commit 标志。

如果您需要更详细的解释或有其他相关问题，请随时联系 OceanBase 技术支持团队获取进一步帮助。

详情请参考:

  1. Redo 日志
  2. 日志存储服务
  3. OceanBase 数据库整体架构
  4. 日志流
  5. 日志流和副本概述
  6. 副本介绍
#22

那既然是同一个日志，在leader副本同步redo日志过来后，在副本中已经有这个事务的redo日志了，在回放任务之后完成后，还会记录一遍这个事务的redo日志吗？@论坛小助手

#23

根据文档库中的信息，可以对您提到的问题进行详细解答。

在 OceanBase 数据库中，Leader 副本同步过来的 Redo 日志与 Follower 副本回放后记录的 Redo 日志确实是同一个日志。那么，在 Leader 副本同步 Redo 日志到 Follower 副本后，Follower 副本是否会在回放任务完成后再次记录一遍这个事务的 Redo 日志呢？

答案是不会。以下是具体原因和机制：

  1. Redo 日志的同步与持久化
    当 Leader 副本生成 Redo 日志并通过 Multi-Paxos 协议同步到 Follower 副本时，Follower 副本会立即将这些日志持久化到本地磁盘。这个过程确保了即使 Leader 副本发生故障，Follower 副本仍然能够通过已接收到的日志恢复数据。
    参考文档: [Redo 日志 → 概述](片段标题: Redo 日志 → 概述)

  2. Redo 日志的回放
    Follower 副本接收到并持久化 Redo 日志后，会对其进行回放以保持与 Leader 副本的数据一致性。回放的过程包括以下几个步骤：

创建事务上下文：为每个事务创建一个事务上下文。
还原操作历史：根据 Redo 日志的内容，在事务上下文中还原出操作历史。
提交事务：当回放到 Commit 日志时，事务提交。

  1. 回放后的处理
    在回放任务完成后，Follower 副本不会再次记录一遍这个事务的 Redo 日志。这是因为：

Redo 日志已经持久化：在 Leader 副本同步 Redo 日志到 Follower 副本时，Follower 副本已经将这些日志持久化到本地磁盘。回放任务只是根据这些日志重新执行事务的操作，并不会生成新的日志。
避免重复记录：如果在回放任务完成后再次记录一遍 Redo 日志，会导致日志的重复记录，增加存储开销并降低系统性能。OceanBase 数据库设计时已经考虑到了这一点，因此不会在回放任务完成后再次记录 Redo 日志。

总结
在 Leader 副本同步 Redo 日志到 Follower 副本后，Follower 副本不会在回放任务完成后再次记录一遍这个事务的 Redo 日志。这是因为 Redo 日志已经在同步过程中被持久化到本地磁盘，回放任务只是根据这些日志重新执行事务的操作，并不会生成新的日志。这种设计避免了日志的重复记录，降低了存储开销并提高了系统性能。

如果您需要更详细的解释或有其他相关问题，请随时联系 OceanBase 技术支持团队获取进一步帮助。

检索到的文档如下:

  1. Redo 日志
  2. OceanBase 数据库整体架构
  3. 日志存储服务
  4. 副本介绍
  5. 日志流
#24

关于这个内部错误的告警，在集群正常运行的情况下，会有什么影响吗？是否可忽略掉这个告警？ @论坛小助手

#25

根据文档库中的信息，可以对您提到的问题进行详细解答。

在 OceanBase 数据库中，Leader 副本同步过来的 Redo 日志与 Follower 副本回放后记录的 Redo 日志是同一个日志。这意味着 Follower 副本在接收到 Leader 副本同步过来的 Redo 日志后，会将其持久化到本地磁盘，并在回放任务完成后不再重复记录该事务的 Redo 日志。

以下是具体的解释：

  1. Redo 日志的同步与持久化

当 Leader 副本生成 Redo 日志并通过 Multi-Paxos 协议同步到 Follower 副本时，Follower 副本会将这些日志持久化到本地磁盘。这个过程确保了即使 Leader 副本发生故障，Follower 副本仍然能够通过已接收到的日志恢复数据。
参考文档: [Redo 日志 → 概述](片段标题: Redo 日志 → 概述)

  1. Redo 日志的回放

Follower 副本在接收到 Redo 日志后，会对其进行回放以保持与 Leader 副本的数据一致性。回放的过程包括以下几个步骤：

创建事务上下文：为每个事务创建一个事务上下文。
还原操作历史：根据 Redo 日志的内容，在事务上下文中还原出操作历史。
提交事务：当回放到 Commit 日志时，事务提交。

  1. 回放完成后是否还会记录一遍 Redo 日志？

不会。Follower 副本在回放完成后，不会再重复记录该事务的 Redo 日志。原因如下：

Redo 日志已经持久化：在 Leader 副本同步 Redo 日志时，Follower 副本已经将其持久化到本地磁盘。因此，不需要在回放完成后再次记录。
避免冗余：重复记录 Redo 日志会导致磁盘空间浪费和性能下降。OceanBase 数据库设计时已经考虑到了这一点，因此在回放完成后不会再次记录 Redo 日志。

总结
在 OceanBase 数据库中，Follower 副本在接收到 Leader 副本同步过来的 Redo 日志后，会将其持久化到本地磁盘，并在回放任务完成后不再重复记录该事务的 Redo 日志。这种设计确保了数据一致性和高可用性，同时避免了冗余记录带来的性能开销。

如果您需要更详细的解释或有其他相关问题，请随时联系 OceanBase 技术支持团队获取进一步帮助。

具体信息可参考以下文档:

  1. Redo 日志
  2. OceanBase 数据库整体架构
  3. 日志存储服务
  4. 副本介绍
  5. 日志流
  6. 日志流和副本概述
#26

关于出现OBServer 非预期的内部错误，具体报错信息如下
[errcode=-4388] Unexpected internal error happen,please checkout the internal errcode(errcode=-4389),file=“ob_ls_adapter.cpp” ,line_no=106,info=“single replay task cost too much time.replay may be delayed” 。这个内部错误的告警，在集群正常运行的情况下，会有什么影响吗？是否可忽略掉这个告警？ @论坛小助手

#27

根据文档库中的信息，可以对您提到的问题进行详细解答。

在 OceanBase 数据库中，Leader 副本同步过来的 Redo 日志与 Follower 副本回放后记录的 Redo 日志是同一个日志。这意味着 Follower 副本在接收到 Leader 副本发送的 Redo 日志后，会将其持久化到本地磁盘，并在回放任务完成后不再重复记录该事务的 Redo 日志。

以下是具体的解释：

  1. Redo 日志的同步与持久化

当 Leader 副本生成 Redo 日志并通过 Multi-Paxos 协议同步到 Follower 副本时，Follower 副本会将这些日志持久化到本地磁盘。这个过程确保了即使 Leader 副本发生故障，Follower 副本仍然能够通过已接收到的日志恢复数据。
参考文档: [Redo 日志 → 概述](片段标题: Redo 日志 → 概述)

  1. Redo 日志的回放

Follower 副本在接收到 Redo 日志后，会对其进行回放以保持与 Leader 副本的数据一致性。回放的过程包括以下几个步骤：

创建事务上下文：为每个事务创建一个事务上下文。
还原操作历史：根据 Redo 日志的内容，在事务上下文中还原出操作历史。
提交事务：当回放到 Commit 日志时，事务提交。

  1. 回放完成后是否还会记录 Redo 日志？

在回放任务完成后，Follower 副本不会再次记录该事务的 Redo 日志。原因如下：

Redo 日志已经持久化：在 Leader 副本同步 Redo 日志时，Follower 副本已经将其持久化到本地磁盘。因此，不需要在回放完成后再次记录。
数据一致性保证：通过回放 Redo 日志，Follower 副本上的数据状态与 Leader 副本一致。再次记录 Redo 日志不会改变数据状态，也没有必要。

总结
在 OceanBase 数据库中，Leader 副本同步过来的 Redo 日志与 Follower 副本回放后记录的 Redo 日志是同一个日志。Follower 副本在接收到 Leader 副本发送的 Redo 日志后，会将其持久化到本地磁盘，并在回放任务完成后不再重复记录该事务的 Redo 日志。

如果您需要更详细的解释或有其他相关问题，请随时联系 OceanBase 技术支持团队获取进一步帮助。

更多信息请查看:

  1. Redo 日志
  2. OceanBase 数据库整体架构
  3. 日志存储服务
  4. 副本介绍
  5. 日志流
  6. 高可用 FAQ
#28

关于出现这个内部错误的告警，在集群正常运行的情况下，会有什么影响吗？是否可忽略掉这个告警？ @论坛小助手

#29

根据文档库中的信息，可以对您提到的问题进行详细解答。

问题分析

在 OceanBase 数据库中，Leader 副本生成 Redo 日志并通过 Multi-Paxos 协议同步到 Follower 副本。Follower 副本接收到 Redo 日志后，会将其持久化到本地磁盘，并通过回放机制确保数据一致性。

关键点：是否会在回放任务完成后再次记录 Redo 日志？

答案是：不会再次记录 Redo 日志。

详细解释

  1. Redo 日志的同步与持久化

    • 当 Leader 副本生成 Redo 日志后，通过 Multi-Paxos 协议将日志同步到 Follower 副本。
    • Follower 副本接收到 Redo 日志后，会立即将其持久化到本地磁盘（Clog 文件）。此时，Follower 副本上已经存在该事务的 Redo 日志。
    • 这一步确保了即使 Leader 副本发生故障，Follower 副本仍然可以通过已接收到的日志恢复数据。

  2. Redo 日志的回放

    • Follower 副本在接收到 Redo 日志并持久化后，会启动回放任务。回放的任务是根据 Redo 日志的内容重新执行事务的操作，以确保副本上的数据状态与 Leader 副本一致。
    • 回放过程中，Follower 副本会创建事务上下文、还原操作历史，并在回放到 Commit 日志时提交事务。

  3. 是否会再次记录 Redo 日志？

    • 在回放任务完成后，Follower 副本不会再次记录该事务的 Redo 日志。因为：
      • Redo 日志已经在 Leader 副本生成并通过 Paxos 协议同步到了 Follower 副本。
      • Follower 副本的职责是接收和回放 Redo 日志，而不是重新生成 Redo 日志。
      • 回放完成后，Follower 副本上的数据状态已经与 Leader 副本一致，无需再记录额外的日志。

  4. 总结流程

    • Leader 副本生成 Redo 日志。
    • Leader 副本通过 Paxos 协议将 Redo 日志同步到 Follower 副本。
    • Follower 副本接收到 Redo 日志后，将其持久化到本地磁盘。
    • Follower 副本启动回放任务，根据 Redo 日志重新执行事务的操作。
    • 回放完成后，Follower 副本不会再次记录该事务的 Redo 日志。

参考文档

  • [Redo 日志 → 概述](片段标题: Redo 日志 → 概述)
  • [Redo 日志 → 日志的产生](片段标题: Redo 日志 → 日志的产生)
  • [Redo 日志 → 日志的回放](片段标题: Redo 日志 → 日志的回放)

总结

在 OceanBase 数据库中，Follower 副本在接收到 Leader 副本同步过来的 Redo 日志后，会将其持久化到本地磁盘并进行回放。回放任务完成后，Follower 副本不会再次记录该事务的 Redo 日志，因为 Redo 日志已经在 Leader 副本生成并通过 Paxos 协议同步完成。

如果您还有其他疑问，请随时联系 OceanBase 技术支持团队获取进一步帮助。

具体信息可参考以下文档:

  1. Redo 日志
  2. OceanBase 数据库整体架构
  3. 日志存储服务
  4. 副本介绍
  5. 日志流
  6. 日志流和副本概述
1 个赞
#30

ddl 是否会记录redo日志？ @论坛小助手

#31

根据文档库中的信息，可以对您提到的 Redo 日志在 Follower 副本中的处理过程进行详细解答。

  1. Leader 同步过来的 Redo 日志与 Follower 回放后记录的 Redo 日志的关系
    如前所述，Leader 副本生成的 Redo 日志通过 Multi-Paxos 协议同步到 Follower 副本。Follower 副本接收到这些日志后，会将其持久化到本地磁盘，并进行回放以保持与 Leader 副本的数据一致性。

  2. Follower 副本是否会再次记录 Redo 日志？
    在 Follower 副本中，不会再次记录同一个事务的 Redo 日志。具体原因如下：

Redo 日志的持久化：
当 Follower 副本接收到 Leader 副本发送的 Redo 日志后，会立即将其持久化到本地磁盘。这个过程确保了即使在回放过程中发生故障，系统仍然可以通过已持久化的日志恢复数据。因此，Redo 日志在接收时就已经被记录下来。

Redo 日志的回放：
Follower 副本在回放 Redo 日志时，只是根据日志内容重新执行事务的操作，以更新本地数据状态。回放的过程并不会生成新的 Redo 日志，而是直接修改数据文件（SSTable）或内存中的数据结构（MemStore）。

Commit 标志的处理：
当回放到 Commit 日志时，事务提交，表示该事务的所有操作已完成。此时，Follower 副本上的数据状态已经与 Leader 副本一致，无需再次记录 Redo 日志。

参考文档: [Redo 日志 → 日志的回放](片段标题: Redo 日志 → 日志的回放)

  1. 总结
    在 Follower 副本中，Redo 日志的处理过程如下：

Leader 副本生成 Redo 日志并通过 Multi-Paxos 协议同步到 Follower 副本。
Follower 副本接收到 Redo 日志后，立即将其持久化到本地磁盘。
Follower 副本根据 Redo 日志的内容进行回放，更新本地数据状态。
回放过程中不会再次记录 Redo 日志，只是根据日志内容重新执行事务的操作。

因此，在 Follower 副本中，不会在回放任务完成后再次记录同一个事务的 Redo 日志。Redo 日志在接收时已经被记录下来，回放的过程只是根据日志内容更新数据状态。

如果您需要更详细的解释或有其他相关问题，请随时联系 OceanBase 技术支持团队获取进一步帮助。

详情请参考:

  1. Redo 日志
  2. OceanBase 数据库整体架构
  3. 日志存储服务
  4. 副本介绍
  5. 日志流
  6. 日志流和副本概述