Row size too large问题

Livedba · 2025 年1 月 6 日 19:57

【使用环境】生产环境 or 测试环境
【 OB or 其他组件】OceanBase 4.2.2.1 4.2.5.1
【使用版本】社区版
【问题描述】一个集群最近从4.2.2.1升级至4.2.5.1，对租户下的database之间进行数据迁移(使用OB导数工具)，在表结构导入中某个表导入失败，手动在目标库创建该表也失败，报 Row size too large错误，表中字段类型大部分为 text。除了改字段类型还有什么其它方法解决，如果修改字符集的话，OB建议修改成什么字符集? 另外，这张表在租户中另一个database存在并且表有数据量表示之前可以创建成功，现在出现 Row size too large错误是版本升级对大字段限制的原因吗?

表结构

迁移报错

【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

论坛小助手 · 2025 年1 月 6 日 20:03

根因分析场景: 无明确的根因分析场景
日志采集场景: 集群基础信息
日志采集命令: obdiag gather scene run --scene=observer.base

为了更好地帮助您解决在 OceanBase 4.2.5.1 版本中从 4.2.2.1 升级后遇到的数据迁移时出现的 “Row size too large” 错误问题，建议您使用 obdiag 工具进行集群基础信息的日志采集。这将有助于我们了解当前集群配置和环境设置，从而进一步分析问题。

请您提供一些额外的信息以便我们更准确地诊断问题：

在升级前后，表结构是否发生了变化？如果有，请详细说明变化内容。
当前租户的字符集设置是什么？可以执行 SHOW CREATE TABLE <table_name>; 和 SELECT * FROM oceanbase.__all_tenant WHERE tenant_id = <tenant_id>; 获取相关信息。
是否对系统参数进行了任何调整，特别是与行大小或存储相关的参数（如 max_allowed_packet、innodb_row_format 等）？
能否提供创建该表的具体 SQL 语句以及报错信息的完整输出？

关于您的问题：

如果修改字符集，OceanBase 建议使用 utf8mb4 字符集，它兼容性好且支持更多字符编码。
表之前可以创建成功而现在出现 “Row size too large” 错误确实可能与版本升级有关，因为不同版本之间可能存在默认配置或内部实现上的差异。通过上述信息收集，我们可以进一步确认这一点。

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

淇铭 · 2025 年1 月 7 日 09:47

如果 SQL 执行立刻报错的，推荐使用系统租户获取 trace_id。
a. 登录系统租户，打开enable_rich_error_msg 参数
alter system set enable_rich_error_msg=true;
b.登录业务租户，执行报错 SQL 语句，会直接返回执行节点 IP 和 trace_id 信息。
obclient [test]> select count(*) from t2;
ERROR 1146 (42S02): Table ‘test.t2’ doesn’t exist
[xx.xx.xx.1:2882] [2024-04-13 20:10:20.292087] [YB420BA1CC68-000615A0A8EA5E38-0-0]
c.去 xx.xx.xx.1 节点过滤日志，如果最新日志无法过滤到，可以正则匹配多个日志进行过滤
[root@x.x.x.1 ~]$ grep “YB420BA1CC68-000615A0A8EA5E38-0-0” rootservice.log
[root@x.x.x.1 ~]$ grep “YB420BA1CC68-000615A0A8EA5E38-0-0” observer.log
d.获取完日志信息后，关闭enable_rich_error_msg参数
alter system set enable_rich_error_msg=false;

根据上面步骤来找一下你执行的命令的日志信息再把完整的observer.log和rootservice.log发一下

我不drop谁drop · 2025 年1 月 7 日 09:54

直接到ocp或者ocp express上批量搜吧，这节点要是多的找着费劲儿

淇铭 · 2025 年1 月 7 日 10:15

先获取到trace_id 在到ocp上搜索也可以看看是哪个节点的日志再到节点上把日志发过来

Livedba · 2025 年1 月 7 日 15:15

稍等，租户运行都正常，就这个表创建报错，但这个表在其他租户中存在，并且有数据，按理说表可以创建成功

论坛小助手 · 2025 年1 月 7 日 15:22

根据您的描述，问题集中在特定表在升级后无法创建，并且报错为 Row size too large。考虑到该表在其他租户中存在并且有数据，这确实表明问题可能与版本升级或特定配置有关。

分析与建议

字符集和行格式：
- 确认当前租户的字符集设置是否一致。可以执行以下命令来检查：
```
SHOW VARIABLES LIKE 'character_set%';
```
- 如果字符集不一致，建议统一使用 utf8mb4 字符集，因为它是更广泛的字符支持标准。
- 检查表的行格式（ROW_FORMAT），确保其设置为 DYNAMIC 或 COMPRESSED，这些格式对大字段有更好的支持。可以通过以下命令查看：
```
SHOW CREATE TABLE <table_name>;
```
表结构优化：
- 从提供的表结构来看，该表包含大量 TEXT 类型字段。TEXT 类型字段占用较多存储空间，可能导致行大小超出限制。
- 考虑将部分 TEXT 字段转换为更小的数据类型，如 VARCHAR，特别是那些实际内容较短的字段。例如：
```
ALTER TABLE <table_name> MODIFY COLUMN attr1 VARCHAR(1024);
```
- 对于确实需要存储大量文本的字段，可以考虑使用 MEDIUMTEXT 或 LONGTEXT，但请注意这些类型也会增加存储开销。
系统参数调整：
- 检查并调整相关系统参数，如 innodb_row_format 和 max_allowed_packet。可以通过以下命令查看当前设置：
```
SHOW VARIABLES LIKE 'innodb_row_format';
SHOW VARIABLES LIKE 'max_allowed_packet';
```
- 如果需要调整，可以在租户级别进行设置：
```
ALTER SYSTEM SET innodb_row_format=DYNAMIC;
ALTER SYSTEM SET max_allowed_packet=1G;
```
版本差异：
- 升级前后可能存在默认配置或内部实现上的差异。建议对比两个版本之间的变更日志，了解是否有影响大字段处理的改动。
- 可以参考 OceanBase 官方文档中关于版本升级的部分，确认是否存在已知问题或建议的最佳实践。
诊断工具：
- 使用 obdiag 工具收集更多诊断信息，特别是关于表结构和存储引擎的状态。这有助于进一步分析问题的根本原因。您可以参考 obdiag 使用帮助链接获取更多信息。

总结

基于上述分析，建议您首先检查并统一字符集和行格式，然后优化表结构以减少行大小。如果问题仍然存在，请使用 obdiag 收集更多诊断信息，并联系 OceanBase 技术支持团队获取进一步帮助。希望这些建议能帮助您解决问题。

详情请参考:

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

撑伞接落花 · 2025 年1 月 7 日 16:08

observer.log.20250107145156009:[2025-01-07 14:51:29.999497] WDIAG [SQL.RESV] check_max_row_data_length (ob_create_table_resolver.cpp:3561) [
55101][T1284_L0_G0][T1284][YB420A260E19-00062A9A8118BBF1-0-0] [lt=4][errcode=-5199] too big rowsize(ret=-5199, ret="OB_ERR_TOO_BIG_ROWSIZE",
 is_oracle_mode=false, i=197, row_data_length=1574684, length=8192)
observer.log.20250107145156009:[2025-01-07 14:51:29.999517] WDIAG [SQL.RESV] resolve (ob_create_table_resolver.cpp:712) [55101][T1284_L0_G0]
[T1284][YB420A260E19-00062A9A8118BBF1-0-0] [lt=14][errcode=-5199] check max row data length failed(ret=-5199)
observer.log.20250107145156009:[2025-01-07 14:51:29.999526] WDIAG [SQL.RESV] stmt_resolver_func (ob_resolver.cpp:177) [55101][T1284_L0_G0][T
1284][YB420A260E19-00062A9A8118BBF1-0-0] [lt=4][errcode=-5199] execute stmt_resolver failed(ret=-5199, parse_tree.type_=3358)
observer.log.20250107145156009:[2025-01-07 14:51:29.999540] WDIAG [SQL] generate_stmt (ob_sql.cpp:3086) [55101][T1284_L0_G0][T1284][YB420A26
0E19-00062A9A8118BBF1-0-0] [lt=7][errcode=-5199] failed to resolve(ret=-5199)
observer.log.20250107145156009:[2025-01-07 14:51:29.999557] WDIAG [SQL] generate_physical_plan (ob_sql.cpp:3207) [55101][T1284_L0_G0][T1284]
[YB420A260E19-00062A9A8118BBF1-0-0] [lt=5][errcode=-5199] Failed to generate stmt(ret=-5199, result.get_exec_context().need_disconnect()=fal
se)
observer.log.20250107145156009:[2025-01-07 14:51:29.999564] WDIAG [SQL] handle_physical_plan (ob_sql.cpp:5098) [55101][T1284_L0_G0][T1284][Y
B420A260E19-00062A9A8118BBF1-0-0] [lt=5][errcode=-5199] Failed to generate plan(ret=-5199, result.get_exec_context().need_disconnect()=false
)
observer.log.20250107145156009:[2025-01-07 14:51:29.999579] WDIAG [SQL] handle_text_query (ob_sql.cpp:2777) [55101][T1284_L0_G0][T1284][YB42
0A260E19-00062A9A8118BBF1-0-0] [lt=4][errcode=-5199] fail to handle physical plan(ret=-5199)
observer.log.20250107145156009:[2025-01-07 14:51:29.999586] WDIAG [SQL] stmt_query (ob_sql.cpp:227) [55101][T1284_L0_G0][T1284][YB420A260E19
-00062A9A8118BBF1-0-0] [lt=5][errcode=-5199] fail to handle text query(stmt=CREATE TABLE `ecar_data` (
observer.log.20250107145156009:[2025-01-07 14:51:29.999604] WDIAG [SERVER] after_func (ob_query_retry_ctrl.cpp:1043) [55101][T1284_L0_G0][T1
284][YB420A260E19-00062A9A8118BBF1-0-0] [lt=3][errcode=-5199] [RETRY] check if need retry(v={force_local_retry:false, stmt_retry_times:0, lo
cal_retry_times:0, err_:-5199, err_:"OB_ERR_TOO_BIG_ROWSIZE", retry_type:0, client_ret:-5199}, need_retry=false)
observer.log.20250107145156009:[2025-01-07 14:51:29.999613] WDIAG [SERVER] do_process (obmp_query.cpp:782) [55101][T1284_L0_G0][T1284][YB420
A260E19-00062A9A8118BBF1-0-0] [lt=6][errcode=-5199] run stmt_query failed, check if need retry(ret=-5199, cli_ret=-5199, retry_ctrl_.need_re
try()=0, sql=CREATE TABLE `ecar_data` (
observer.log.20250107145156009:[2025-01-07 14:51:29.999624] WDIAG [SQL] move_to_sqlstat_cache (ob_sql_stat_record.cpp:360) [55101][T1284_L0_
G0][T1284][YB420A260E19-00062A9A8118BBF1-0-0] [lt=8][errcode=0] the key is not valid which at plan cache mgr(ret=0, ret="OB_SUCCESS")
observer.log.20250107145156009:[2025-01-07 14:51:29.999630] WDIAG [SERVER] do_process (obmp_query.cpp:918) [55101][T1284_L0_G0][T1284][YB420
A260E19-00062A9A8118BBF1-0-0] [lt=3][errcode=-5199] query failed(ret=-5199, session={this:0x7ed266ff24e8, id:3222214148, deser:false, tenant
:"BMS_ALM", tenant_id:1284, effective_tenant:"BMS_ALM", effective_tenant_id:1284, database:"bmsalm_dev", user:"root@%", consistency_level:3,
 session_state:2, autocommit:true, tx:null}, sql=CREATE TABLE `ecar_data` (
observer.log.20250107145156009:[2025-01-07 14:51:29.999657] INFO  [SERVER] send_error_packet (obmp_packet_sender.cpp:383) [55101][T1284_L0_G
0][T1284][YB420A260E19-00062A9A8118BBF1-0-0] [lt=13]  REACH SYSLOG RATE LIMIT [bandwidth]
observer.log.20250107145156009:[2025-01-07 14:51:29.999689] INFO  [SERVER] send_error_packet (obmp_packet_sender.cpp:586) [55101][T1284_L0_G
0][T1284][YB420A260E19-00062A9A8118BBF1-0-0] [lt=7] dump txn free route audit_record(value=5, session->get_sessid()=3222214148, session->get
_proxy_sessid()=731287485925279991)

淇铭 · 2025 年1 月 7 日 16:13

这个时间段的整个日志压缩也发一下

淇铭 · 2025 年1 月 7 日 18:19

看着是行长超过了最大的范围完整的日志在发一下

淇铭 · 2025 年1 月 8 日 17:40

表结构保存在文里提供一下？内部复现一下看看

Livedba · 2025 年1 月 8 日 19:38

好的，晚点我发你

Livedba · 2025 年1 月 8 日 21:57

table.txt (10.4 KB)

淇铭 · 2025 年1 月 9 日 10:21

好的内部先复现看看

淇铭 · 2025 年1 月 9 日 11:25

424 更改了lob_inrow_threshold的默认值（从4K改为了8K）建表时，可以显示指定下lob_inrow_threshold
eg：create table (xxxx) lob_inrow_threshold=4096

Livedba · 2025 年1 月 9 日 15:07

可以了，学到了