oceanbase备份错误

OceanBase 技术问题
#1

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

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

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

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

使用obdumper工具备份,truncate表以后就没问题，可以加相关参数解决吗，有底层原因吗，对表结构有要求吗

#3

根据您提供的信息，看起来您在使用 obdumper 工具备份 OceanBase 数据库时遇到了一个问题，具体表现为在导出非分区表 “hello” 的数据时，由于主键字段 ti_status 的值为空而导致失败。这里有几个方面可以考虑：

  1. 主键字段不能为空：

    • 在 OceanBase 中，主键字段是不允许为空的。如果您的表设计允许 ti_status 字段为空，那么这可能是导致备份失败的原因之一。建议检查表的设计，确保主键字段没有空值。

  2. 使用 TRUNCATE 表后的成功备份：

    • 您提到在使用 TRUNCATE 表之后备份成功了。这是因为 TRUNCATE 操作会删除表中的所有数据，并重置自增主键等元数据，因此备份时不会遇到主键为空的情况。

  3. 解决方案：

    • 检查并清理数据：在备份之前，确保表中的所有主键字段都没有空值。可以使用以下 SQL 语句来查找并清理这些记录：
      DELETE FROM hello WHERE ti_status IS NULL;
    • 使用 obdumper 参数：obdumper 工具本身并没有专门的参数来处理主键为空的情况，但可以通过预处理数据来避免这个问题。

  4. 表结构要求：

    • 确保表的主键字段定义为 NOT NULL，并且在插入数据时始终提供有效的主键值。这是数据库设计的最佳实践，不仅有助于备份，还能提高数据的一致性和完整性。

  5. 进一步排查：

    • 如果上述方法仍然无法解决问题，建议使用 obdiag 工具收集诊断信息，以便更深入地分析问题。您可以按照以下步骤操作：
      obdiag collect -c <cluster_name> -d <diagnose_dir>

综上所述，建议您先检查并清理表中的主键为空的数据，然后再进行备份。如果问题依然存在，可以使用 obdiag 收集更多的诊断信息，以便进一步排查。希望这些信息对您有所帮助！

检索到的文档如下:

  1. 错误码
  2. OceanBase 安装部署工具 V1.6.0
  3. 角色切换与解耦
  4. OPTIMIZE
  5. 创建分区表
  6. ALTER TABLEGROUP
#4

逻辑导出的命名可以发一下吗

#6

可以发一下表结构么

#7

oceanbase主键字段是id，为什么日志里面会出现 The value of primary key “ti_status” is null 为什么日志里面认为ti_status 是主键

#8

根据您提供的信息，日志中出现了“The value of primary key 'ti_status' is null”的错误提示，但您提到表的主键字段是 id。这种情况可能有以下几种原因：

  1. 表结构变更：

    • 检查表结构是否发生了变更。可能在某个时间点，ti_status 被错误地设置为主键，然后又被更改回 id。这种情况下，某些旧数据或缓存可能仍然保留了 ti_status 作为主键的信息。
    • 使用以下 SQL 语句检查当前表的主键：
      SHOW CREATE TABLE hello;

  2. 数据导入或迁移问题：

    • 如果您是从其他数据库导入或迁移数据，可能存在数据导入时的错误，导致某些记录的主键字段被错误地设置为 ti_status。
    • 检查数据导入或迁移的脚本，确保主键字段正确设置为 id。

  3. 应用程序逻辑问题：

    • 检查应用程序的逻辑，确保在插入或更新数据时，主键字段始终设置为 id，而不是 ti_status。
    • 查看应用程序的日志，确认是否有任何地方错误地将 ti_status 作为主键使用。

  4. 备份工具配置问题：

    • 检查 obdumper 工具的配置文件，确保没有错误地将 ti_status 作为主键处理。
    • 查看 obdumper 的文档和配置选项，确保没有遗漏任何配置。

  5. 数据一致性问题：

    • 如果表中有数据不一致的情况，可能会导致备份工具在处理数据时出现错误。
    • 使用以下 SQL 语句检查表中是否存在 ti_status 为空的记录：
      SELECT * FROM hello WHERE ti_status IS NULL;

  6. 日志解析问题：

    • 日志中的错误信息可能被错误解析，导致显示了不正确的主键字段。检查日志文件的格式和解析逻辑，确保日志信息的准确性。

综合建议

  1. 检查表结构：

    • 运行 SHOW CREATE TABLE hello; 确认当前表的主键字段。

  2. 检查数据：

    • 运行 SELECT * FROM hello WHERE ti_status IS NULL; 查找并清理 ti_status 为空的记录。

  3. 检查应用程序逻辑：

    • 确认应用程序在插入或更新数据时，主键字段始终设置为 id。

  4. 检查备份工具配置：

    • 确认 obdumper 工具的配置文件，确保没有错误地将 ti_status 作为主键处理。

  5. 收集诊断信息：

    • 如果问题依然存在，建议使用 obdiag 工具收集更多的诊断信息，以便进一步排查：
      obdiag collect -c <cluster_name> -d <diagnose_dir>

希望这些信息能帮助您解决问题。如果还有其他疑问或需要进一步的帮助，请随时联系 OceanBase 的技术支持团队。

详情请参考:

  1. 主键表和无主键表
  2. 5000 ~ 5999
  3. 4000 ~ 4499
  4. 0001 ~ 3999
  5. log_archive_concurrency
  6. log_restore_concurrency

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

#9

麻烦发下表结构（建议脱敏）以及导出命令

obdumper版本及oceanbase版本也麻烦发下

#10

obdumper -hip -P 2881 -u hello@sys -p “$password” -D “$type” --ddl --all --table ‘*’ -f “$backup_ddl”

# 执行表数据相关备份操作

obdumper -hip -P 2881 -u hello@sys -p “$password” -D “$type” --csv --table ‘*’ -f “$backup_data”

oceanbase版本：4.2.2

obdumper版本: /data/backup/ob-loader-dumper-4.2.1-RELEASE/bin/obdumper

#11

用最新的obloader-dumper-4.2.4导出

2024-11-25 11:16:43 [INFO] Found null in unique constraints columns [id,ti_status], abort splitting table “hello” 这个报错什么意思

#12

用最新的ob-loader-dumper备份正常了