obdumper错误

OceanBase 技术问题
#1

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

导出数据
Splitting rows for non-partitioned table: “hello_ticket” failed… Reason: The value of primary key “ti_status” is null

#3

根据您提供的信息，obdumper 导出数据时遇到错误，具体错误信息为：

Splitting rows for non-partitioned table: "hello_ticket" failed. Reason: The value of primary key "ti_status" is null

这个错误表明在导出非分区表 hello_ticket 时，主键 ti_status 的值为 null，这违反了主键的唯一性和非空约束。

解决方法

  1. 检查数据：

    • 确认表 hello_ticket 中是否有主键 ti_status 为 null 的记录。可以使用以下 SQL 查询来检查：
      SELECT * FROM hello_ticket WHERE ti_status IS NULL;

  2. 处理 null 值：

    • 如果确实存在 null 值，您需要决定如何处理这些记录。可以选择以下几种方法之一：
      • 更新数据：将 null 值更新为有效的值。例如：
        UPDATE hello_ticket SET ti_status = 'some_value' WHERE ti_status IS NULL;
      • 删除数据：如果这些记录不重要，可以直接删除。例如：
        DELETE FROM hello_ticket WHERE ti_status IS NULL;
      • 忽略这些记录：如果 obdumper 支持忽略某些记录的选项，可以尝试使用这些选项。

  3. 重新导出数据：

    • 在处理完 null 值后，重新运行 obdumper 导出数据。

注意事项

  • 备份数据：在执行任何更新或删除操作之前，请确保已经备份了相关数据，以防止数据丢失。
  • 验证数据：在更新或删除数据后，再次验证数据的完整性和一致性。

如果您还有其他问题或需要进一步的帮助，请提供更多详细信息，以便我们更好地为您解答。

详情请参考:

  1. OceanBase 安装部署工具 V1.6.0
  2. 错误码
  3. IMPORT_INDEX_STATS
  4. 使用 OceanBase 导数工具从 OceanBase 集群 Oracle 租户迁移数据到 MySQL 租户
  5. 使用 OceanBase 导数工具在 OceanBase 集群 MySQL 租户间迁移数据
  6. 查询集群信息
  7. 获取任务的详细信息
  8. 获取 Node 的详细信息
  9. 查询 Agent 未完成的任务
#4

可以参考小助手给的方法先自查一下

#5

有底层的备份原因吗，对表结构有什么要求吗

#6

根据文档库中的信息，OceanBase 的备份和恢复功能对表结构有一些特定的要求。以下是相关的要点：

表结构要求

  1. 主键：

    • 必须有主键：每个表都应该有一个主键。如果用户未指定主键，系统会自动生成一个隐藏主键。但是，为了更好的性能和数据管理，建议显式定义主键。
    • 主键非空：主键字段不能为 null。这是导致您遇到 obdumper 错误的主要原因之一。

  2. 字段类型：

    • 避免使用复杂的数据类型：如 blob 或 json。这些类型可能会增加备份和恢复的复杂性。
    • 推荐使用简单的数据类型：如 int、varchar、timestamp 等。

  3. 字段属性：

    • 推荐使用 NOT NULL 属性：所有字段推荐设置为 NOT NULL，以确保数据的一致性和完整性。
    • 定义默认值：业务可以根据需要定义字段的默认值。

  4. 表必备字段：

    • gmt_create 和 gmt_modified：建议每个表包含这两个字段，用于记录数据的创建时间和修改时间。这些字段的类型可以是 DATE 或 TIMESTAMP WITH TIME ZONE。

备份原因

  1. 数据高可靠性：

    • 多副本容灾复制：OceanBase 通过多副本机制实现数据的高可用性和容灾能力。
    • 回收站：用于恢复误删除的表或库。
    • 物理备库：用于数据的异步复制和备份。
    • 备份恢复：作为保护用户数据的最后一道防线，备份恢复功能可以恢复因各种原因导致的数据丢失或损坏。

  2. 备份类型：

    • 数据备份：存储层的基线和转储数据，即备份时刻的 Major SSTable + Minor SSTable。
    • 日志备份：事务层生成的 Clog，包含 SSTable 之后修改的数据。

  3. 备份介质：

    • 支持的备份介质：NFS、阿里云 OSS、腾讯云 COS、AWS S3 以及兼容 S3 协议的对象存储，如华为 OBS、Google GCS。
    • 备份介质要求：部分备份介质可能需要满足一些基本要求，具体要求参见 物理备份与恢复概述 中的 备份介质要求。

总结

  • 主键要求：每个表必须有主键，且主键字段不能为 null。
  • 字段类型和属性：推荐使用简单的数据类型，字段应设置为 NOT NULL 并定义默认值。
  • 必备字段：建议每个表包含 gmt_create 和 gmt_modified 字段。
  • 备份原因：备份和恢复是保护数据高可靠性的核心组件，通过多副本、回收站、物理备库和备份恢复等多种机制实现。

希望这些信息能帮助您更好地理解和解决 obdumper 错误。如果有更多问题，请随时联系 OceanBase 的人工答疑以获取更多帮助。

更多信息请查看:

  1. 备份前准备
  2. SQL FAQ
  3. 并行执行调优技巧
  4. backup_dest
  5. SET LOG_ARCHIVE_DEST
  6. 表结构设计
  7. oceanbase.DBA_OB_BACKUP_SET_FILES
  8. Truncate 分区
  9. RENAME TABLE
  10. 备份恢复概述

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

#7

需要主键 对结构没有什么限制， 部分临时表和系统表是无法导出的

#8

oceanbase4.2.2，开始ob-loader-dumper-4.2.1-RELEASE有问题，改为ob-loader-dumper-4.2.4-RELEASE可以解决

1 个赞