OCP告警处理

OceanBase 技术问题
#1

ocp告警信息：update a too too smaller reserved snapshot!!!
出现这个告警的原因是什么？如何处理？

3 个赞
#3

@论坛小助手

3 个赞
#4

根据文档库中的信息，关于“update a too too smaller reserved snapshot!!!”这一具体告警，并没有直接提及。但我们可以结合OCP告警处理的相关内容进行分析和推测。

告警原因分析

  1. 可能与合并过程有关
    根据文档片段6的信息，“OCP 管理每个 OceanBase 集群合并是否正常，若有合并出错则上报告警。” 这表明该告警可能与OceanBase集群的合并操作（如Minor Freeze或Major Freeze）相关。如果保留的快照点过小，可能导致合并过程中数据完整性受到影响，从而触发告警。

  2. 快照保留空间不足
    “Reserved Snapshot”通常指的是OceanBase在合并过程中保留的历史数据快照。如果快照保留的空间过小，可能会导致合并失败或数据丢失风险增加，进而触发此告警。

处理方法

以下是基于OCP告警处理经验和文档信息的建议：

1. 检查合并配置

  • 登录OCP平台，进入对应集群的管理页面。
  • 检查合并相关的参数配置，例如minor_freeze_times、major_freeze_duty_time等。
  • 确保保留的快照点大小足够，避免因快照过小导致问题。

2. 调整保留快照点大小

  • 如果确认是保留快照点过小的问题，可以通过以下SQL语句调整：
    ALTER SYSTEM SET freeze_trigger_percentage = 70;
    上述语句将触发合并的阈值调整为70%（可根据实际需求调整）。通过增大触发合并的条件，间接增加保留快照点的大小。

3. 排查慢SQL或大事务

  • 如果集群中存在长时间运行的大事务或慢SQL，可能会导致合并过程异常，从而触发此类告警。
  • 在OCP平台上查看SlowSQL告警（如有），并优化相关SQL语句。

4. 升级OCP版本

  • 根据文档片段9的信息，部分OCP版本可能存在兼容性问题或性能瓶颈。建议将OCP升级至最新稳定版本（如V3.3.0及以上），以获得更好的告警处理能力和性能优化。

5. 联系技术支持

  • 如果上述方法无法解决问题，建议收集相关日志信息（如OceanBase日志、OCP告警日志）并联系OceanBase官方技术支持团队进一步排查。

总结

虽然文档中未明确提到“update a too too smaller reserved snapshot!!!”的具体原因，但结合OCP告警机制和OceanBase合并原理，可以推测该告警与合并过程中的快照保留空间不足有关。建议按照上述步骤逐一排查并优化相关配置。

如果仍有疑问，可提供更多上下文信息以便进一步分析。

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

  1. base_backup_timeout 数据备份任务超时
  2. base_backup_fail 数据备份任务失败
  3. OCP V4.0.1
  4. refresh_location_cache_failed_by_metric OBServer 刷新 location cache 失败
  5. base_secondary_backup_fail 数据二次备份任务失败
  6. ob_cluster_merge_error OB 集群合并出错
  7. ocp_alarm_detect_timeout OCP 告警规则检测超时
  8. 自定义告警可选监控指标
  9. OCP V3.3.0
4 个赞
#5

可以详细讲解一下转储和合并的详细过程吗？能否举例说明@论坛小助手

3 个赞
#6

根据文档库中的信息，以下是对OceanBase数据库中转储和合并的详细过程的讲解，并结合具体例子进行说明。

转储（Dump）的详细过程

  1. MemTable 冻结 (Minor Freeze)
    当 MemTable 的大小超过一定阈值时，系统会触发 Minor Freeze 操作。此时，当前活跃的 MemTable 会被冻结，不再接受新的写入操作，同时生成一个新的活跃 MemTable 来继续接收后续的数据写入。

  2. 数据刷盘
    被冻结的 MemTable 中的数据会被刷写到磁盘上，形成一个 SSTable 文件。这个过程就是所谓的转储（Dump）。转储完成后，SSTable 文件会被添加到 L0 层。

  3. 分层转储策略
    根据文档片段3和8的信息，从 V2.2 版本开始，OceanBase 引入了分层转储策略。L0 层采用 size-tiered compaction 策略，而 L1 和 L2 层则基于宏块粒度维持 leveled compaction。这意味着：

    • 在 L0 层，当 SSTable 文件数量较多或达到一定大小时，会触发内部的 Compaction 操作，将多个小文件合并成较大的文件。
    • 在 L1 和 L2 层，Compaction 会确保数据在不同层次之间有序分布，减少读取时的 I/O 开销。

示例：转储过程

假设有一个 MemTable，初始大小为 1GB。当其大小达到 1.5GB 时，触发 Minor Freeze：

  • 原有的 MemTable 被冻结，生成一个新的 MemTable 继续接收写入。
  • 被冻结的 MemTable 数据被刷写到磁盘，形成一个 1.5GB 的 SSTable 文件，存放在 L0 层。

如果 L0 层已经有多个 SSTable 文件（例如 1GB、2GB 和 3GB），系统可能会触发 Compaction 操作，将这些文件合并成一个更大的 SSTable 文件（如 6GB），并将其移动到 L1 层。

合并（Merge）的详细过程

  1. 每日合并 (Major Freeze)
    合并操作通常发生在每天凌晨 2 点左右的业务低峰期（具体时间可配置）。系统会选取一个全局快照点，基于该快照点对所有分区的数据进行 Major Compaction。

  2. 动静态数据归并
    合并操作会将当前大版本的 SSTable 和 MemTable 中的数据与前一个大版本的全量静态数据进行归并，生成新的全量数据。这一过程可以理解为“重新整理”整个存储空间，减少冗余数据。

  3. 数据压缩
    根据文档片段5的信息，在合并期间，OceanBase 会对数据进行两层压缩：

    • 第一层是基于语义的编码压缩。
    • 第二层是基于用户指定压缩算法（如 lz4）的通用压缩。
      这种双重压缩机制不仅节省了存储空间，还提升了查询性能。

  4. 物理数据校验
    合并过程中，系统会利用全局一致位点对多副本以及主表和索引表进行多维度的物理数据校验，确保数据一致性。

示例：合并过程

假设当前有以下 SSTable 文件：

  • L0 层：1GB、2GB、3GB
  • L1 层：6GB
  • L2 层：10GB

在每日合并时：

  • 系统选取一个全局快照点，基于该快照点对所有分区的数据进行 Major Compaction。
  • 将 L0、L1 和 L2 层的所有 SSTable 文件进行归并，生成一个新的 22GB 的 SSTable 文件。
  • 新生成的 SSTable 文件会替换原有的所有文件，成为最新的全量数据。

总结

  • 转储 是将 MemTable 中的数据刷写到磁盘上，形成 SSTable 文件的过程。它通过分层转储策略（size-tiered 和 leveled compaction）来优化数据存储结构。
  • 合并 是将动静态数据进行归并，生成新的全量数据的过程。它通过双重压缩和物理数据校验来提升性能和数据一致性。

希望以上讲解和示例能够帮助您更好地理解 OceanBase 数据库中的转储和合并机制！

更多信息请查看:

  1. 转储和合并概述
  2. 存储架构概述
  3. 转储
  4. 生态集成概述
  5. OceanBase 数据库性能的影响因素
  6. 系统视图总览
  7. 转储管理概述
  8. OceanBase 概述
  9. 章节介绍
4 个赞
#7

:+1: :+1: :+1: :+1:

3 个赞
#8

在这个举例中，哪些步骤涉及快照功能了，又是如何使用快照以及这个快照出现告警的，请举例说明 @论坛小助手

2 个赞
#9

根据文档库中的信息，以下是对快照功能在转储和合并过程中的具体使用场景的详细讲解，并结合告警情况举例说明。

快照功能的使用场景

1. 全局快照点的选择

在 OceanBase 数据库中，合并（Merge） 操作会选取一个全局快照点。这个快照点的作用是确保所有分区的数据基于同一时间点进行归并，从而生成一致性的全量数据。

  • 使用场景：在每日合并时，系统会选取一个全局快照点，基于该快照点对所有分区的数据进行 Major Compaction。
  • 作用：通过全局快照点，OceanBase 能够保证合并过程中数据的一致性，避免因并发写入导致的数据不一致问题。

2. 快照点与数据校验

在合并过程中，OceanBase 利用全局快照点对多副本以及主表和索引表进行多维度的物理数据校验。这种校验机制能够发现潜在的数据一致性问题。

  • 使用场景：当合并操作完成时，系统会基于快照点对数据进行校验，确保所有副本的数据一致。
  • 作用：如果发现数据不一致，系统会触发告警，提示用户可能存在数据丢失或损坏的风险。

快照相关的告警示例

告警类型：update a too too smaller reserved snapshot!!!

根据文档片段的信息，以下是可能涉及快照功能的告警场景及处理方法：

1. 保留快照点过小

如果保留的快照点过小，可能会导致以下问题：

  • 原因：保留快照点的大小不足以覆盖合并所需的基线数据，可能导致合并失败或数据丢失。
  • 告警描述：update a too too smaller reserved snapshot!!!
  • 影响：合并操作无法正常进行，可能导致查询性能下降或数据一致性问题。

示例场景

假设当前有以下 SSTable 文件：

  • L0 层：1GB、2GB、3GB
  • L1 层：6GB
  • L2 层：10GB

在每日合并时：

  1. 系统选取了一个全局快照点，基于该快照点对所有分区的数据进行 Major Compaction。
  2. 如果保留的快照点过小（例如仅保留了 5GB 的数据），而实际需要的基线数据为 10GB，则会导致合并失败。
  3. 系统会触发告警：update a too too smaller reserved snapshot!!!

解决方法

  1. 检查保留快照点的配置

    • 登录 OCP 平台，进入对应集群的管理页面。
    • 检查 freeze_trigger_percentage 参数，确保其值合理（如设置为 70%）。
    • SQL 示例：ALTER SYSTEM SET freeze_trigger_percentage = 70;

  2. 调整合并策略

    • 如果业务对查询性能要求较高，建议开启自适应合并功能（从 V4.1.0 版本开始支持）。自适应合并可以根据用户的查询和写入信息动态调整合并任务。
    • 参考文档：《自适应合并》

  3. 排查慢 SQL 或大事务

    • 如果集群中存在长时间运行的大事务或慢 SQL，可能会导致合并过程异常。
    • 在 OCP 平台上查看 SlowSQL 告警，并优化相关 SQL 语句。

2. 快照点更新失败

如果快照点更新失败，可能会导致以下问题：

  • 原因：系统在尝试更新快照点时遇到错误，可能是由于磁盘空间不足或数据损坏。
  • 告警描述：snapshot update failed
  • 影响：合并操作中断，可能导致数据一致性问题。

示例场景

假设当前有以下 SSTable 文件：

  • L0 层：1GB、2GB、3GB
  • L1 层：6GB
  • L2 层：10GB

在每日合并时：

  1. 系统尝试更新快照点，但由于磁盘空间不足，更新失败。
  2. 系统触发告警：snapshot update failed

解决方法

  1. 检查磁盘空间

    • 确保磁盘空间充足，避免因空间不足导致快照点更新失败。
    • 使用以下命令检查磁盘空间：df -h

  2. 清理不必要的数据

    • 删除旧的 SSTable 文件或日志文件，释放磁盘空间。
    • SQL 示例：ALTER SYSTEM MAJOR FREEZE; 强制触发合并，清理冗余数据。

  3. 联系技术支持

    • 如果问题仍未解决，建议收集相关日志信息（如 OceanBase 日志、OCP 告警日志）并联系 OceanBase 官方技术支持团队进一步排查。

总结

快照功能在 OceanBase 数据库的转储和合并过程中扮演着重要角色，主要体现在以下几个方面：

  1. 全局快照点的选择：确保合并过程中数据的一致性。
  2. 数据校验：利用快照点对多副本数据进行物理校验，发现潜在的一致性问题。

当出现与快照相关的告警时（如 update a too too smaller reserved snapshot!!! 或 snapshot update failed），可以通过以下步骤进行排查和处理：

  • 检查保留快照点的配置。
  • 调整合并策略。
  • 排查慢 SQL 或大事务。
  • 确保磁盘空间充足。

希望以上讲解和示例能够帮助您更好地理解快照功能及其在告警场景中的应用！

详情请参考:

  1. 管理 WR
  2. 自适应合并
  3. 手动控制合并
  4. 转储和合并概述
  5. 存储架构概述
  6. 系统视图总览
  7. OceanBase 数据库性能的影响因素
  8. OceanBase 迁移服务（OMS）
2 个赞
#10

全局快照点是什么？可以举例说明吗？是否类似scn的时间戳？@论坛小助手

1 个赞
#11

根据文档库中的信息，以下是对全局快照点的详细讲解，并结合具体例子进行说明。

全局快照点是什么？

全局快照点 是 OceanBase 数据库在执行某些操作（如合并、备份等）时选取的一个时间点或逻辑位置。它用于确保所有分区的数据基于同一时间点进行处理，从而生成一致性的全量数据。全局快照点通常与系统内部的时间戳（如 SCN）密切相关。

特点

  1. 一致性保证：全局快照点能够确保在该时间点之前的所有数据都被完整捕获，避免因并发写入导致的数据不一致问题。
  2. 逻辑位置：全局快照点不仅是一个时间戳，还可能包含其他元信息（如事务版本号），用于标识数据库的状态。
  3. 分布式特性：在分布式环境中，全局快照点需要跨多个节点和副本保持一致性。

全局快照点是否类似 SCN 的时间戳？

是的，全局快照点与 SCN（System Change Number，系统变更号）非常相似，但它们的概念略有不同：

  • SCN 是一个逻辑的时间戳，表示事务提交时的版本号。OceanBase 使用 SCN 来标记事务的顺序和数据的一致性状态。
  • 全局快照点 是基于 SCN 的一个具体时间点，用于定义某个操作（如合并或备份）的基准线。

两者的关系可以理解为：全局快照点是 SCN 的一种应用形式，用于标记特定的操作基线。

示例说明

假设我们有一个 OceanBase 集群，其中存储了以下数据：

时间戳 (SCN) 数据内容
100 A=1, B=2
200 A=3, B=4
300 A=5, B=6

场景 1：每日合并

每天凌晨 2 点，OceanBase 会触发一次 Major Freeze（大合并）。在这个过程中，系统会选择一个全局快照点（例如 SCN=200）作为基准线。

  • 合并过程：

    • 基于 SCN=200 的数据（A=3, B=4）进行归并。
    • 忽略 SCN=200 之后的数据（A=5, B=6），以确保合并结果的一致性。

  • 结果：

    • 合并完成后，生成一个新的 SSTable 文件，包含 SCN=200 之前的所有数据。

场景 2：备份恢复

假设我们需要对集群进行备份，并选择 SCN=100 作为全局快照点。

  • 备份过程：

    • 备份系统会捕获 SCN=100 之前的所有数据（A=1, B=2）。
    • 忽略 SCN=100 之后的数据（A=3, B=4 和 A=5, B=6）。

  • 恢复过程：

    • 如果需要恢复到 SCN=100 的状态，系统会还原备份中的数据（A=1, B=2），忽略后续的更改。

总结

  1. 全局快照点 是 OceanBase 数据库中用于标记特定操作（如合并、备份等）基准线的时间点或逻辑位置。
  2. 它与 SCN 密切相关，可以理解为 SCN 的一种具体应用形式。
  3. 通过全局快照点，OceanBase 能够确保在分布式环境中数据的一致性和完整性。

希望以上讲解和示例能够帮助您更好地理解全局快照点的概念及其与 SCN 的关系！如果还有其他疑问，请随时提问。

检索到的文档如下:

  1. oceanbase.DBA_WR_SNAPSHOT
  2. oceanbase.CDB_WR_SNAPSHOT
  3. 全局时间戳
  4. oceanbase.DBA_OB_DATA_DICTIONARY_IN_LOG
  5. OceanBase 数据库整体架构
  6. 设置日志恢复终点
  7. 全链路追踪概述
  8. SCN_TO_TIMESTAMP
2 个赞
#12

这个举例能否结合update a too too smaller reserved snapshot 告警信息，详细讲解下过程和处理方法
@论坛小助手

1 个赞
#13

根据文档库中的信息，以下是对 update a too too smaller reserved snapshot 告警的详细讲解，并结合每天凌晨 2 点触发 Major Freeze（大合并）的过程进行说明。

背景知识：全局快照点与保留快照

在 OceanBase 数据库中，全局快照点 是指在执行某些操作（如合并、备份等）时选取的一个时间点或逻辑位置。它用于确保所有分区的数据基于同一时间点进行处理，从而生成一致性的全量数据。而 保留快照 是指系统在合并过程中需要保留的历史数据版本，以支持后续的查询和恢复操作。

当触发 Major Freeze（大合并）时，系统会选取一个全局快照点作为基准线，将当前的动态数据与静态数据归并，生成新的全量数据。如果保留的快照点过小，可能导致合并失败或数据丢失风险增加，进而触发 update a too too smaller reserved snapshot 告警。

示例场景：每天凌晨 2 点触发 Major Freeze

假设我们有一个 OceanBase 集群，其存储结构如下：

时间戳 (SCN) 数据内容
100 A=1, B=2
200 A=3, B=4
300 A=5, B=6

正常情况下的 Major Freeze 过程

每天凌晨 2 点，OceanBase 触发 Major Freeze 操作，具体过程如下：

  1. 选取全局快照点
    系统选择 SCN=200 作为全局快照点，表示基于该时间点之前的所有数据进行合并。

  2. 归并数据
    系统将 SCN=200 之前的数据（A=3, B=4）与静态数据归并，生成新的 SSTable 文件。

  3. 清理旧数据
    合并完成后，系统会清理 SCN=200 之前的旧数据，仅保留最新的全量数据。

异常情况：触发 update a too too smaller reserved snapshot 告警

告警原因分析

如果保留的快照点过小，可能会导致以下问题：

  1. 保留快照点不足以覆盖合并所需的基线数据
    例如，假设系统需要保留 SCN=100 的数据作为基线，但实际只保留了 SCN=200 的数据，则会导致合并失败。

  2. 合并过程中数据丢失风险增加
    如果保留快照点过小，可能导致部分历史数据被清理，影响后续的查询和恢复操作。

示例场景

假设当前有以下 SSTable 文件：

  • L0 层：1GB、2GB、3GB
  • L1 层：6GB
  • L2 层：10GB

在每日 Major Freeze 时：

  1. 系统尝试选取 SCN=200 作为全局快照点。
  2. 如果保留的快照点过小（例如仅保留了 SCN=300 的数据），则无法覆盖 SCN=200 的基线数据。
  3. 系统触发告警：update a too too smaller reserved snapshot!!!

处理方法

1. 检查保留快照点的配置

登录 OCP 平台，进入对应集群的管理页面，检查以下参数：

  • freeze_trigger_percentage
    该参数控制触发合并的阈值。建议将其设置为合理的值（如 70%），以确保保留足够的快照点。
ALTER SYSTEM SET freeze_trigger_percentage = 70;

2. 调整合并策略

如果业务对查询性能要求较高，建议开启自适应合并功能（从 V4.1.0 版本开始支持）。自适应合并可以根据用户的查询和写入信息动态调整合并任务。

参考文档：《自适应合并》

3. 排查慢 SQL 或大事务

长时间运行的大事务可能会导致合并过程异常。在 OCP 平台上查看 SlowSQL 告警，并优化相关 SQL 语句。

4. 确保磁盘空间充足

检查磁盘空间是否充足，避免因空间不足导致快照点更新失败。

使用以下命令检查磁盘空间：

df -h

如果磁盘空间不足，可以删除旧的 SSTable 文件或日志文件，释放磁盘空间。

ALTER SYSTEM MAJOR FREEZE; -- 强制触发合并，清理冗余数据

5. 联系技术支持

如果问题仍未解决，建议收集相关日志信息（如 OceanBase 日志、OCP 告警日志）并联系 OceanBase 官方技术支持团队进一步排查。

总结

update a too too smaller reserved snapshot 告警通常与保留快照点过小有关，可能导致合并失败或数据丢失风险增加。通过以下步骤可以有效排查和解决问题：

  1. 检查保留快照点的配置（如 freeze_trigger_percentage 参数）。
  2. 调整合并策略（如开启自适应合并功能）。
  3. 排查慢 SQL 或大事务。
  4. 确保磁盘空间充足。
  5. 必要时联系技术支持。

希望以上讲解能够帮助您更好地理解该告警的成因及处理方法！如果还有其他疑问，请随时提问。

详情请参考:

  1. 手动控制合并
  2. oceanbase.DBA_OB_FREEZE_INFO
  3. oceanbase.CDB_OB_FREEZE_INFO
  4. 4500 ~ 4999
  5. 4000 ~ 4499
  6. 存储架构概述
  7. freeze_trigger_percentage
  8. 自适应合并
  9. 9000 ~ 9499
2 个赞
#14

快照时间设置的太短了么

1 个赞
#15

保留快照也是个时间戳吗？那保留快照的数据包含mem table 和sstable 吗？还是只涉及sstable ？

update a too too smaller reserved snapshot!!!那这个告警的原因是因为转储的策略配置太小导致快速转储快照而不能保留之前版本的数据吗？

@论坛小助手

#16

根据文档库中的信息，以下是关于保留快照、其数据范围以及 update a too too smaller reserved snapshot!!! 告警原因的详细解答。

1. 保留快照是否是时间戳？

保留快照并不是严格意义上的时间戳，但它与时间戳（如 SCN）密切相关。保留快照点是一个逻辑标识，用于标记某个特定时刻的数据状态。它不仅包含时间戳信息，还可能涉及事务版本号等元信息，以确保在该时间点之前的所有数据都被完整捕获。

2. 保留快照的数据范围：是否包含 MemTable 和 SSTable？

保留快照的数据范围主要涉及 SSTable，而不直接包含 MemTable。具体原因如下：

  • MemTable 是内存中的数据结构，主要用于存储最新的写入数据。当触发 Minor Freeze（小合并）时，MemTable 中的数据会被刷写到磁盘上，形成 SSTable 文件。
  • SSTable 是磁盘上的持久化数据文件，包含了历史数据的多个版本。保留快照点的作用是确保在某个时间点之前的数据版本能够被完整保留，而这些数据版本主要存储在 SSTable 中。

因此，保留快照的数据范围主要是 SSTable，而不是 MemTable。不过，MemTable 的数据会在 Minor Freeze 后被转储为 SSTable，并成为保留快照的一部分。

3. update a too too smaller reserved snapshot!!! 告警的原因

该告警的原因并非单纯因为转储策略配置太小导致快速转储快照而不能保留之前版本的数据。以下是更详细的分析：

告警的核心原因

update a too too smaller reserved snapshot!!! 告警通常是因为 保留快照点过小，无法覆盖合并所需的基线数据。具体来说：

  • OceanBase 在执行 Major Freeze（大合并）时，会选取一个全局快照点作为基准线。
  • 如果保留快照点过小（例如仅保留了较新的数据版本），则可能导致以下问题：
    • 合并失败：系统无法基于保留的快照点生成一致性的全量数据。
    • 数据丢失风险增加：部分历史数据可能被清理，影响后续的查询和恢复操作。

转储策略的影响

虽然转储策略（如 undo_retention 参数）确实会影响多版本数据的保留时间，但它并不是该告警的唯一原因。以下因素也可能导致告警：

  1. freeze_trigger_percentage 参数配置不合理

    • 该参数控制触发合并的阈值。如果设置过低，可能会导致保留的快照点过小。
    • 示例：ALTER SYSTEM SET freeze_trigger_percentage = 70;

  2. 磁盘空间不足

    • 如果磁盘空间不足，系统可能会被迫清理旧的 SSTable 文件，从而导致保留快照点过小。

  3. 长时间运行的大事务

    • 长时间运行的大事务可能会占用较多的多版本数据空间，导致保留快照点无法覆盖所有必要的历史数据。

  4. 日志归档延迟配置不合理

    • 如果 archive_lag_target 参数设置过小，可能会导致日志归档过于频繁，从而影响保留快照点的大小。
    • 示例：ALTER SYSTEM SET archive_lag_target = '120s';

4. 综合处理方法

针对 update a too too smaller reserved snapshot!!! 告警，可以采取以下措施进行排查和解决：

  1. 检查保留快照点的配置

    • 登录 OCP 平台，进入对应集群的管理页面，检查以下参数：
      • freeze_trigger_percentage：建议设置为合理的值（如 70%）。
      • undo_retention：确保多版本数据的保留时间足够长。
    • 示例 SQL：
      ALTER SYSTEM SET freeze_trigger_percentage = 70;
ALTER SYSTEM SET undo_retention = '86400'; -- 保留 1 天的多版本数据

  2. 调整日志归档延迟

    • 检查 archive_lag_target 参数，确保其值合理（如 120 秒）。
    • 示例 SQL：
      ALTER SYSTEM SET archive_lag_target = '120s';

  3. 排查慢 SQL 或大事务

    • 在 OCP 平台上查看 SlowSQL 告警，并优化相关 SQL 语句。
    • 如果存在长时间运行的大事务，建议尽快结束或拆分事务。

  4. 确保磁盘空间充足

    • 使用以下命令检查磁盘空间：
      df -h
    • 如果磁盘空间不足，可以删除旧的 SSTable 文件或日志文件，释放磁盘空间。
    • 示例 SQL：
      ALTER SYSTEM MAJOR FREEZE; -- 强制触发合并，清理冗余数据

  5. 联系技术支持

    • 如果问题仍未解决，建议收集相关日志信息（如 OceanBase 日志、OCP 告警日志）并联系 OceanBase 官方技术支持团队进一步排查。

总结

  • 保留快照 是一个逻辑标识，主要用于标记某个时间点之前的数据状态，其数据范围主要涉及 SSTable，而不直接包含 MemTable。
  • update a too too smaller reserved snapshot!!! 告警的原因可能是多方面的，包括但不限于转储策略配置不合理、磁盘空间不足、长时间运行的大事务等。
  • 通过检查相关参数（如 freeze_trigger_percentage 和 undo_retention）、调整日志归档延迟、排查慢 SQL 或大事务、确保磁盘空间充足等措施，可以有效解决该告警问题。

希望以上解答能够帮助您更好地理解保留快照的概念及其与告警的关系！如果还有其他疑问，请随时提问。

更多信息请查看:

  1. undo_retention
  2. 转储
  3. 设置日志同步限速
  4. 存储架构概述
  5. 备份架构
  6. 日志归档前准备
  7. DBMS_WORKLOAD_REPOSITORY 概述
  8. 4000 ~ 4499
#17

保留快照点和全局快照点所使用的sstable 是一份数据吗？还是保留快照维护自己的一套sstable ？
保留快照是否和undo 表空间类似？
归档都归档哪些文件？
@论坛小助手

#18

根据文档库中的信息，以下是关于保留快照点、全局快照点、保留快照与 undo 表空间的关系以及归档内容的详细解答。

1. 保留快照点和全局快照点所使用的 SSTable 是一份数据吗？还是保留快照维护自己的一套 SSTable？

答案：保留快照点和全局快照点所使用的 SSTable 是同一份数据，而不是独立维护的两套 SSTable。

详细解释

  • 全局快照点 是 OceanBase 在执行某些操作（如合并或备份）时选取的一个时间点或逻辑位置，用于标记当前的数据状态。
  • 保留快照点 是为了支持多版本并发控制（MVCC）而保留的历史数据版本。它确保在某个时间点之前的数据不会被清理，以支持后续的查询或恢复操作。

两者都依赖于同一个 SSTable 数据集，但它们的作用不同：

  • 全局快照点主要用于定义合并或备份的基准线。
  • 保留快照点则用于确保历史数据版本能够被完整保留。

SSTable 文件本身并不会因为全局快照点或保留快照点的存在而产生额外的副本。OceanBase 通过引用计数机制来管理 SSTable 文件的生命周期。只有当所有引用（包括全局快照点和保留快照点）都被释放后，SSTable 文件才会被清理。

2. 保留快照是否和 undo 表空间类似？

答案：保留快照与 undo 表空间的功能有相似之处，但实现方式不同。

详细解释

  • undo 表空间 是传统数据库（如 Oracle 或 MySQL InnoDB）中用于存储事务回滚信息和多版本数据的空间。它专门用于记录旧版本的数据行，以便支持事务回滚和 MVCC 查询。
  • 保留快照 在 OceanBase 中是通过 SSTable 文件实现的，而不是单独的 undo 表空间。OceanBase 的 LSM-Tree 架构决定了其多版本数据直接存储在 SSTable 文件中，而不是像传统数据库那样存储在独立的 undo 表空间中。

具体区别如下：

特性 undo 表空间（传统数据库） 保留快照（OceanBase）
存储位置 独立的 undo 表空间 SSTable 文件
数据结构 专门的回滚段 多版本数据直接存储在 SSTable 中
生命周期管理 回滚段由系统自动清理 SSTable 文件通过引用计数机制管理
主要用途 支持事务回滚和 MVCC 查询 支持 MVCC 查询和数据恢复

因此，虽然两者功能上有相似之处（如支持多版本数据），但实现方式完全不同。

3. 归档都归档哪些文件？

答案：归档主要归档重做日志文件（Redo Log），而不归档 SSTable 文件或其他元数据文件。

详细解释

根据文档片段 5 和 7 的信息，OceanBase 的归档功能主要包括以下内容：

  1. 重做日志文件（Redo Log）

    • 归档的核心是将数据库产生的重做日志存储到其他介质（如 NFS 或 OSS）中，从而可以更长时间地保存数据库的所有重做历史操作记录。
    • 每个租户可以独立决定是否开启日志归档功能，各租户之间的日志归档相互不影响。

  2. 归档范围

    • 归档只涉及重做日志文件，而不涉及 SSTable 文件或其他元数据文件。
    • 这是因为 SSTable 文件已经通过物理备份功能进行了保护，而重做日志文件则是为了支持增量恢复和高可用性。

  3. 归档周期

    • 默认情况下，日志归档的周期为 2 分钟，提供了准实时的备份能力。
    • 默认按 24 小时拆分目录的功能，方便用户对备份数据进行管理。

示例场景

假设一个 OceanBase 集群每天生成 10GB 的重做日志文件，归档功能会将这些日志文件逐步归档到外部存储（如 NFS 或 OSS）。如果需要恢复到某个时间点，可以通过以下步骤完成：

  1. 使用最近一次的物理备份恢复数据。
  2. 应用归档的重做日志文件，恢复到目标时间点。

总结

  1. 保留快照点和全局快照点所使用的 SSTable 是同一份数据，OceanBase 通过引用计数机制管理 SSTable 文件的生命周期。
  2. 保留快照与 undo 表空间的功能有相似之处，但实现方式不同。保留快照直接利用 SSTable 文件存储多版本数据，而 undo 表空间是独立的存储区域。
  3. 归档主要归档重做日志文件，而不涉及 SSTable 文件或其他元数据文件。归档功能结合物理备份，可以提供完整的数据恢复能力。

希望以上解答能够帮助您更好地理解这些概念！如果还有其他疑问，请随时提问。

详情请参考:

  1. undo_retention
  2. 转储和合并概述
  3. 数据库对象存储
  4. OceanBase 数据库整体架构
  5. 日志归档概述
  6. OceanBase 数据库性能的影响因素
  7. 备份架构
  8. 存储架构概述
  9. 转储
#19

大事物和大查询都会增加sstable 的引用计数吗？
sstable 的引用计数不为0时，会影响合并吗？合并后生成新的基线和sstable 引用计数不为0的多版本同时存在吗？
@论坛小助手

#20

根据文档库中的信息，以下是关于大事务和大查询对 SSTable 引用计数的影响、SSTable 引用计数不为 0 时是否影响合并以及合并后生成新的基线与多版本数据共存情况的详细解答。

1. 大事务和大查询都会增加 SSTable 的引用计数吗？

答案：是的，大事务和大查询都会增加 SSTable 的引用计数。

详细解释

  • 大事务
    在 OceanBase 数据库中，为了支持多版本并发控制（MVCC），每个事务都需要访问其开始时的数据快照。这意味着事务会持有某些 SSTable 文件的引用，以确保在事务执行期间不会清理这些文件。如果一个事务持续时间较长（即大事务），它可能会引用多个版本的 SSTable 文件，从而增加这些文件的引用计数。

  • 大查询
    类似地，大查询也可能需要访问较旧版本的数据，尤其是在涉及历史数据或复杂查询的情况下。这种情况下，查询会持有相关 SSTable 文件的引用，同样会导致这些文件的引用计数增加。

因此，无论是大事务还是大查询，只要它们需要访问特定版本的数据，就会增加相应 SSTable 文件的引用计数。

2. SSTable 的引用计数不为 0 时，会影响合并吗？

答案：SSTable 的引用计数不为 0 时，确实会影响合并过程。

详细解释

  • 合并的基本原则
    OceanBase 的合并操作（如 Minor Merge 和 Major Merge）会将多个 SSTable 文件归并成一个新的 SSTable 文件，以减少文件数量并优化查询性能。然而，在合并过程中，OceanBase 必须确保不会清理仍在使用的 SSTable 文件。

  • 引用计数的作用
    如果某个 SSTable 文件的引用计数不为 0，说明该文件仍被某些事务或查询所使用。在这种情况下，OceanBase 不会清理该文件，而是将其保留到所有引用都被释放为止。这可能导致以下情况：

    • 合并操作无法立即清理旧的 SSTable 文件。
    • 合并完成后，旧的 SSTable 文件可能仍然存在一段时间，直到其引用计数降为 0。

因此，SSTable 的引用计数不为 0 时，确实会影响合并的效率和存储空间的回收。

3. 合并后生成新的基线和 SSTable 引用计数不为 0 的多版本同时存在吗？

答案：是的，合并后生成的新基线和引用计数不为 0 的多版本数据可以同时存在。

详细解释

  • 新基线的生成
    在 Major Merge（大合并）完成后，系统会生成一个新的全量 SSTable 文件作为新的基线。这个新基线包含了当前时间点的所有数据。

  • 多版本数据的共存
    然而，由于某些事务或查询可能仍然引用旧版本的数据，这些旧的 SSTable 文件不会立即被清理。因此，在一段时间内，新基线和旧版本的 SSTable 文件会同时存在。

  • 具体场景
    假设在 Major Merge 完成后，系统生成了一个新的全量 SSTable 文件（新基线）。但此时，某个长时间运行的大事务仍然引用了旧版本的 SSTable 文件。在这种情况下：

    • 新基线会被用于后续的查询和写入操作。
    • 旧版本的 SSTable 文件会继续保留，直到该大事务完成并释放其引用。

这种机制确保了 OceanBase 能够在支持多版本数据的同时，逐步清理不再需要的历史数据。

总结

  1. 大事务和大查询都会增加 SSTable 的引用计数，因为它们需要访问特定版本的数据。
  2. SSTable 的引用计数不为 0 时会影响合并，因为 OceanBase 不会清理仍在使用的 SSTable 文件。
  3. 合并后生成的新基线和引用计数不为 0 的多版本数据可以同时存在，以确保多版本数据的一致性和完整性。

希望以上解答能够帮助您更好地理解这些机制！如果还有其他疑问，请随时提问。

检索到的文档如下:

  1. 转储和合并
  2. OceanBase 数据库性能的影响因素
  3. JOIN 表使用建议
  4. 转储和合并概述
  5. 并行 DML
  6. SQL FAQ
  7. V$OB_COMPACTION_SUGGESTIONS
  8. 工作线程
1 个赞