列名乱码导致查询报异常invalid field name

【详述】
有遇过表无法查询 ,报异常invalid field name, 但写入正常的情况吗?

starrocks 2.3.13的版本 ,看了下原因是表schema字段名乱码 ,导致查询匹配不上 , 此表是5BUCKETS 3副本 ,发现其中一个tablet错误 ,也就是三个副本的tablet全部错误了 ,但其他的12个tablet正常 , where查询如果绕过错误的tablet还是可以正常查的 , 具体字段与乱码对应是appId -> 9 url-> E\u0017 tag-> E\u0017 pv-> E\u0017 ,聚合表 ,DISTRIBUTED BY HASH(appId, url) ,该集群主要现象是这一两个月be时常崩溃 , 我门是写脚本监测到后主动拉起的 , 查询开始错误的期间并没有alter表 ,不知道是不是be崩溃导致元数据错误了?

另外副本是陆续损坏的 ,看日志一开始不确定是损坏一个还是两个 所以查询有时候失败 不过重试又好了 ,所以一直没有发现 ,写入也一直正常 ,甚至无法查询后写入flink任务也正常, 但不确定是否真的写入成功了 ,但看15个tablet 的 data size都差不多 , 并不是损坏的tablet就数据少很多了

“schema”: {
“keys_type”: “AGG_KEYS”,
“column”: [
{
“unique_id”: 0,
“name”: “���9”,
“type”: “VARCHAR”,
“is_key”: true,
“aggregation”: “NONE”,
“is_nullable”: true,
“precision”: 0,
“frac”: 0,
“length”: 65535,
“index_length”: 20,
“is_bf_column”: true,
“has_bitmap_index”: false
},
{
“unique_id”: 1,
“name”: “��E\u0017”,
“type”: “VARCHAR”,
“is_key”: true,
“aggregation”: “NONE”,
“is_nullable”: true,
“precision”: 0,
“frac”: 0,
“length”: 65535,
“index_length”: 20,
“is_bf_column”: true,
“has_bitmap_index”: false
},
{
“unique_id”: 2,
“name”: “�E\u0017”,
“type”: “INT”,
“is_key”: true,
“aggregation”: “NONE”,
“is_nullable”: true,
“precision”: 0,
“frac”: 0,
“length”: 4,
“index_length”: 4,
“is_bf_column”: false,
“has_bitmap_index”: false
},
{
“unique_id”: 3,
“name”: “��E\u0017”,
“type”: “BIGINT”,
“is_key”: false,
“aggregation”: “SUM”,
“is_nullable”: true,
“precision”: 0,
“frac”: 0,
“length”: 8,
“index_length”: 8,
“is_bf_column”: false,
“has_bitmap_index”: false
}
],
“num_short_key_columns”: 1,
“num_rows_per_row_block”: 1024,
“compress_kind”: “COMPRESS_LZ4”,
“bf_fpp”: 0.05,
“next_column_unique_id”: 4
},

表结构如下:
CREATE TABLE table_test (
appId varchar(65533) NULL COMMENT “”,
url varchar(65533) NULL COMMENT “”,
tag int(11) NULL COMMENT “”,
pv bigint(20) SUM NULL COMMENT “”
) ENGINE=OLAP
AGGREGATE KEY(appId, url, tag)
COMMENT “OLAP”
DISTRIBUTED BY HASH(appId, url) BUCKETS 5
PROPERTIES (
“replication_num” = “3”,
“bloom_filter_columns” = “appId, url”,
“in_memory” = “false”,
“storage_format” = “DEFAULT”,
“enable_persistent_index” = “false”
);

【背景】无
【业务影响】 无法查询
【StarRocks版本】例如:2.3.13
【集群规模】
【机器信息】
【联系方式】社区群8-tempo
【附件】 看需要提供什么

发一下宕机的be节点的 be.out 日志

be(2).out (188.5 KB) be(1).out (173.3 KB) be.out (260.5 KB)

好的 这三个节点崩溃日志如上 ,请再帮忙看下了 谢谢

请问有进展吗 谢谢

为什么写入的数据乱码,数据库默认支持UTF8

问题有解决么?3.1.4遇到了相同的问题

当时是找官方的人员 ,使用meta_tool.sh 强制把错误的meta覆盖修复
官方没有文挡 ,doris这有类似的
https://doris.apache.org/zh-CN/docs/dev/admin-manual/maint-monitor/tablet-meta-tool/

  1. ./bin/meta_tool.sh --operation=get_meta --root_path=/path/to/storage/path --tablet_id=tabletid,保存下json格式的meta
  2. 修改meta并保存
  3. ./bin/meta_tool.sh --operation=load_meta --root_path=/path/to/storage/path --json_meta_path=path

改的时后最好是3台都改了,或者改一台然后把另外两个副本set bad处理掉

感谢老哥,这个问题处理之后再也没复现了吗?有排查到具体原因吗?