3.3.5 PK 表查询多次数据不一致

💬 StarRocks 用户问答
#1

为了更快的定位您的问题，请提供以下信息，谢谢
【详述】问题详细描述
【背景】做过哪些操作

下面3个查询的结果都不一样，看profile是查到了不同的副本上

mysql> select count(1) from dwd_report_order where company_id=90136113084612608 and store_id=‘110399702994764288’ group by store_id;
±---------+
| count(1) |
±---------+
| 48339 |
±---------+
1 row in set (0.01 sec)

mysql> select count(1) from dwd_report_order where company_id=90136113084612608 and store_id=‘110399702994764288’ group by store_id;
±---------+
| count(1) |
±---------+
| 7984 |
±---------+
1 row in set (0.00 sec)

mysql> select count(1) from dwd_report_order where company_id=90136113084612608 and store_id=‘110399702994764288’ group by store_id;
±---------+
| count(1) |
±---------+
| 5701 |
±---------+
1 row in set (0.01 sec)

explain 的sql：

mysql> explain select count(1) from dwd_report_order where company_id=90136113084612608 and store_id=‘110399702994764288’ group by store_id;
±---------------------------------------------------------------------------------------+
| Explain String |
±---------------------------------------------------------------------------------------+
| PLAN FRAGMENT 0 |
| OUTPUT EXPRS:77: count |
| colocate exec groups: ExecGroup{groupId=0, nodeIds=[0, 1, 2, 3]} |
| PARTITION: RANDOM |
| |
| RESULT SINK |
| |
| 3:Project |
| | <slot 77> : 77: count |
| | |
| 2:AGGREGATE (update finalize) |
| | output: count(1) |
| | group by: 2: store_id |
| | |
| 1:Project |
| | <slot 2> : 2: store_id |
| | |
| 0:OlapScanNode |
| TABLE: dwd_report_order |
| PREAGGREGATION: ON |
| PREDICATES: 1: company_id = 90136113084612608, 2: store_id = ‘110399702994764288’ |
| partitions=1/1 |
| rollup: dwd_report_order |
| tabletRatio=1/1024 |
| tabletList=6605521 |
| cardinality=8 |
| avgRowSize=26.0 |
±---------------------------------------------------------------------------------------+

看tablet 的副本都是normal状态

mysql> SHOW PROC ‘/dbs/10184/6051984/partitions/6051983/6603920/6605521’;
±----------±----------±--------±------------±------------------±----------------------±-----------------±---------------------±--------------------±-----------±----------±---------±-------±------±--------------±-------------±---------------------±--------------------------------------------------±---------------------------------------------------------------------------------------±-------------+
| ReplicaId | BackendId | Version | VersionHash | LstSuccessVersion | LstSuccessVersionHash | LstFailedVersion | LstFailedVersionHash | LstFailedTime | SchemaHash | DataSize | RowCount | State | IsBad | IsSetBadForce | VersionCount | PathHash | MetaUrl | CompactionStatus | IsErrorState |
±----------±----------±--------±------------±------------------±----------------------±-----------------±---------------------±--------------------±-----------±----------±---------±-------±------±--------------±-------------±---------------------±--------------------------------------------------±---------------------------------------------------------------------------------------±-------------+
| 6605522 | 6464006 | 513784 | 0 | 513784 | 0 | -1 | 0 | NULL | 1696497272 | 192565196 | 2500887 | NORMAL | false | false | 356 | -5863101841537184957 | http://xxx:8040/api/meta/header/6605521 | http://xxx:8040/api/compaction/show?tablet_id=6605521&schema_hash=1696497272 | false |
| 6605523 | 6356131 | 513784 | 0 | 513784 | 0 | -1 | 0 | NULL | 1696497272 | 187173914 | 2500887 | NORMAL | false | false | 44 | 1720694507208494185 | http://xxx:8040/api/meta/header/6605521 | http://xxx:8040/api/compaction/show?tablet_id=6605521&schema_hash=1696497272 | false |
| 6605524 | 6526711 | 513780 | 0 | 513780 | 0 | 513784 | 0 | 2024-12-18 11:52:39 | 1696497272 | 212628022 | 2500887 | NORMAL | false | false | 91 | 3116429720073172711 | http://xxx:8040/api/meta/header/6605521 | http://xxx:8040/api/compaction/show?tablet_id=6605521&schema_hash=1696497272 | false |
±----------±----------±--------±------------±------------------±----------------------±-----------------±---------------------±--------------------±-----------±----------±---------±-------±------±--------------±-------------±---------------------±--------------------------------------------------±---------------------------------------------------------------------------------------±-------------+
【业务影响】查询数据异常
【是否存算分离】否
【StarRocks版本】例如：3.3.5
【集群规模】例如：3fe（3 follower）+7be
【机器信息】CPU虚拟核/内存/网卡，例如：48C/64G/万兆
【联系方式】社区群3-杨荣
【附件】
cnt_profile_1.txt (20.5 KB) cnt_profile_3.txt (20.4 KB) cnt_profile_2.txt (20.4 KB)

查询dump的文件
cnt_dump_file (17.6 KB)

show create table 查看表结构
show_create_table (5.7 KB)

#2

找到几个类似的贴子看了下可能的问题，query_cache 的值是false的，排查掉cache的问题
enable_pipeline_load 这个值设置成了false 也还是有问题，应该跟这个也没个关系
导入只有stream_load的方式

#3

@许秀不许秀 @trueeyu大佬们有空可以帮忙看看吗

#4

通过以下命令 dump 出来了3个 short_key_index
./bin/meta_tool.sh --operation=dump_short_key_index --file=</path/to/segment/file> --key_column_count=6

short_key_dump_10 (76.0 KB) short_key_dump_223 (73.4 KB) short_key_dump_124 (73.4 KB)

对比发现3个文件里面的short key的顺序都不一致

#5

数据量不大是吧？ 这三个副本每个都只有一个segment文件么？
是只做了一次导入？ 还是最后comapction之后生成了一个segment文件？
要不grep一下tabletid，把be.INFO里面的相关信息也提供下，另外metatool dump一下tablet的meta

#6

嗯，数据量是不大
导入了很多次，3个节点上的segment文件都不一样
稍等我把日志及tabelt的meta也提供一下

#7

要不也ls -l 一下几个tablet文件夹内容

#8

嗯，没问题的，稍等

#9

223
2231098×751 100 KB
124
1241032×752 100 KB
10
101044×890 113 KB

#10

另外你dump的是哪几个segment文件？ 之前的截图最好提供的txt版本

#11

124
/data1/StarRocks/be/storage/data/1017/6605521/1696497272/020000008ded054b8d4d2fafc76a885619fe823325bbb5be_0.dat
223
/data1/StarRocks/be/storage/data/808/6605521/1696497272/020000008baa0d30534d12e58b1c9e22202f6ee0e073108c_0.dat
10
/data1/StarRocks/be/storage/data/831/6605521/1696497272/020000008e7790c7964376d6b9423f45086041c72bc3518b_0.dat

#12

昨天用./bin/meta_tool.sh --operation=dump_short_key_index dump 的是这几个文件

#13

今天看这些文件不存在了

#14

我要重新dump 一下最新的.dat 文件的 short_key_index 和 meta 出来再看下吗?

#15

我重新导一下最新的.dat 文件的 meta 和 short_key_index出来再看看吧

#16

三个副本的数据文件肯定是对应不上的，你的意思是三个文件里面的数据都是乱序的是吧？

#17

另外我看里面有很多cols文件，你这边做了列式部分列更新？ 还是用了update语句？能把更新或者update语句也发下么？ 可能是这块有问题

#18

开发那边反馈之前有用过update sql进行更新，最近都没有了，这个我找下开发确认下

#19

dump 出来的 short_key_index 的顺序是不一样的

#20

业务那边反馈只用过这种delete sql, 11月后都不用了，搞成stream_load了
DELETE
FROM
dwd_report_order
WHERE
company_id = ?
AND platform_code =?
AND store_id in (?)
AND platform_order_no in ( ? , ? )
AND CONCAT(store_id, ‘-’, platform_order_no) in ( ? , ? )
AND CONCAT(store_id, ‘-’, platform_order_no, ‘-’, order_item_no, ‘-’, order_type, ‘-’, trade_report_id) not in ( ? , ? )
AND order_type not in (‘FT1’, ‘FT2’)

京ICP备2022026421号-1