批量导入数据报错

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】
【 使用版本 】Server version: OceanBase_CE 4.2.1.8 (r108000022024072217-3149c25ca2dadbb7707686ad02a1367b1b43e0b5)
【问题描述】从mysqldump出来的数据，source到OB，偶尔会报错，导出语法如下，修改下面参数后问题依旧 set global max_allowed_packet=1073741824;
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
mysqldump -h127.0.0.1 -uadmin -p -P3306 --add-drop-database=true --force --lock-tables=false --skip-triggers --skip-comments --compact -N -t testdb >/home/123.sql

obclient [testdb]> source /home/123.sql
ERROR 4013 (HY001): No memory or reach tenant memory limit
ERROR 2013 (HY000): Lost connection to MySQL server during query
ERROR 2006 (HY000): OceanBase server has gone away
No connection. Trying to reconnect…
Connection id: 3221650593

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

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

#3

用户问题: “在使用 mysqldump 导入数据到 OceanBase 时遇到错误 4013，如何解决？”

推荐使用 obdiag 工具进行日志采集，并且将采集到的日志提供给我们以便确认问题所在。

日志采集场景: SQL 执行出错
日志采集命令: obdiag gather scene run --scene=observer.sql_err --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”

请您先执行上述命令来收集相关日志，并将生成的日志压缩包发送给我们。这将有助于我们更快地定位问题。

为了进一步了解您的问题，请您提供以下信息：

  1. 您能否提供错误的具体信息或错误日志？
  2. 您在执行 mysqldump 导入操作时是否遇到了特定的表或数据？
  3. 您是否尝试过使用其他工具或方法导入数据？结果如何？
  4. 您当前使用的 OceanBase 版本是什么？
  5. 是否可以提供导入脚本的一部分内容或数据示例？

详情请参考:

  1. 0001 ~ 3999
  2. 4000 ~ 4499

附上敏捷诊断工具 obdiag 使用帮助链接

#4

2000多张普通表，字段个数几个到200，表数据量大部分是空表，有些表的数据量几十到几万

#5

根据您提供的信息，您正在尝试导入包含2000多张普通表的数据，这些表的字段数量从几个到200个不等，且大多数表为空表，部分表的数据量在几十到几万之间。您在导入过程中遇到了错误代码4013（No memory or reach tenant memory limit）以及错误代码2013（Lost connection to MySQL server during query）。

错误代码4013（No memory or reach tenant memory limit）表明在执行SQL语句的过程中，内存不足或达到了租户内存的限制。这可能是由于以下原因导致的：

  1. 租户内存限制：OceanBase数据库中的租户内存限制可能设置得较低，导致在导入大量数据时内存不足。
  2. 单个SQL语句过大：在导入数据时，如果单个SQL语句过大，可能会导致内存不足。

错误代码2013（Lost connection to MySQL server during query）表明在执行SQL语句的过程中，与服务器的连接丢失。这可能是由于以下原因导致的：

  1. 连接超时：在导入大量数据时，如果单个SQL语句执行时间过长，可能会导致连接超时。
  2. 服务器负载过高：如果服务器负载过高，可能会导致连接丢失。

针对这些问题，您可以尝试以下解决方案：

  1. 增加租户内存限制：如果您有足够的物理内存，可以考虑增加租户内存限制。具体操作可以参考OceanBase官方文档中的相关章节。
  2. 拆分SQL语句：如果单个SQL语句过大，可以考虑将其拆分成多个较小的SQL语句。例如，可以将一个大的INSERT语句拆分成多个较小的INSERT语句。
  3. 优化导入过程：在导入数据时，可以考虑使用OceanBase提供的批量导入工具，如OMS（OceanBase Migration Service），它可以更高效地处理大批量数据的导入。
  4. 增加连接超时时间：可以尝试增加客户端的连接超时时间，以避免在执行长时间SQL语句时连接超时。具体操作可以参考OceanBase官方文档中的相关章节。
  5. 减少服务器负载：在导入数据时，尽量避免其他高负载的操作，以减少服务器负载。

希望以上建议能够帮助您解决问题。如果问题仍然存在，建议您联系OceanBase的技术支持团队获取进一步的帮助。

检索到的文档如下:

  1. 集群管理 FAQ
  2. 使用限制
  3. information_schema.TABLES
  4. 删除数据
  5. 表存储
  6. 创建表
  7. 统计信息概述
  8. 对象命名规范综述
  9. OBKV-HBase 数据模型

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

#6

参考下这个帖子，大概率是租户内存不足，发下observer.log看下

image
image1534×842 146 KB

脚本数据导入OB报错ERROR 4013 (HY001) at line 4: No memory or reach tenant memory limit改如何优化 - #5，来自 tony5413hao1lf_gaMTIwMjU5NTAzNC4xNzE0OTc1MTY1_ga_T35KTM57DZ*MTcyNzI0MjUwMy4yMjkuMS4xNzI3MjQzMzgxLjI0LjAuMA…

#7

感谢，从日志里面看确实是内存不够了，不过我刚部署ob，还不会增加租户内存，待我研究研究先

[2024-09-25 19:02:58.880944] WDIAG [SQL.PC] add_plan (ob_plan_cache.cpp:1043) [17660][T1_L0_G0][T1][YB42AC10460A-000622C12BDAD6C1-0-0] [lt=5][errcode=-5226] plan cache memory used reach limit(tenant_id=1, get_mem_hold()=54165504, get_mem_limit()=53687090, ret=-5226)
[2024-09-25 19:02:58.880952] WDIAG [SQL] pc_add_plan (ob_sql.cpp:4378) [17660][T1_L0_G0][T1][YB42AC10460A-000622C12BDAD6C1-0-0] [lt=7][errcode=-5226] some unexpected error occured(ret=-5226)
[2024-09-25 19:02:58.880955] WDIAG [SQL] handle_physical_plan (ob_sql.cpp:4804) [17660][T1_L0_G0][T1][YB42AC10460A-000622C12BDAD6C1-0-0] [lt=3][errcode=-5787] fail to add plan to plan cache(ret=-5787)
[2024-09-25 19:02:58.880958] WDIAG [SQL] handle_text_query (ob_sql.cpp:2561) [17660][T1_L0_G0][T1][YB42AC10460A-000622C12BDAD6C1-0-0] [lt=2][errcode=-5787] fail to handle physical plan(ret=-5787)
[2024-09-25 19:02:58.880962] WDIAG [SQL] stmt_query (ob_sql.cpp:222) [17660][T1_L0_G0][T1][YB42AC10460A-000622C12BDAD6C1-0-0] [lt=3][errcode=-5787] fail to handle text query(stmt=INSERT INTO alarm_notify_policy (alarm_notify_policy_id, alarm_type_id, target_id, alarm_level) VALUES
(3, 323181, 1, ‘1’),
(4, 312180, 1, ‘2’),
(5, 312127, 1, ‘1’),
(6, 219, 1, ‘1’),
(7, 217, 1, ‘1’),
(8, 215, 1, ‘1’),
(9, 107, 1, ‘1’),
(10, 130, 1, ‘3’),
(11, 131, 1, ‘3’), ret=-5787)