关于频繁刷has few replica日志

💬 StarRocks 用户问答 数据导入与导出
#1

【详述】频繁报has few replica
backend [11001] invalid situation. tablet[12752] has few replica[1], replica num setting is [1]
每秒报几十条，全天没停过，极度消耗服务器性能
【导入/导出方式】routine load
【背景】做过哪些操作？
根据错误日志中的tabletID查找到对应库为：statistics 表名为：table_statistic_v1，将此表drop然后重新建replication_num=2的此表，但仍一直刷日志
【业务影响】
影响其他错误日志定位；
每秒刷几十条日志，而且全天不停，消耗服务器性能和磁盘空间
【StarRocks版本】StarRocks version 1.18.2
【集群规模】1fe+2be分开部署
【机器信息】8核32G
【附件】错误日志.txt (754.5 KB)

#2

请问下有动态分区表么

#3

没有，目前数据量最大的表才1500w条数据，都没建分区表。

#4

show tablet $tablet_id确认下是table_statistic_v1这个表嘛？看了下这个表默认应该是2副本

另外可以按照下面语句创建下table_statistic_v1表

CREATE TABLE `table_statistic_v1` (
  `table_id` bigint(20) NOT NULL COMMENT "",
  `column_name` varchar(65530) NOT NULL COMMENT "",
  `db_id` bigint(20) NOT NULL COMMENT "",
  `table_name` varchar(65530) NOT NULL COMMENT "",
  `db_name` varchar(65530) NOT NULL COMMENT "",
  `row_count` bigint(20) NOT NULL COMMENT "",
  `data_size` bigint(20) NOT NULL COMMENT "",
  `distinct_count` bigint(20) NOT NULL COMMENT "",
  `null_count` bigint(20) NOT NULL COMMENT "",
  `max` varchar(65530) NOT NULL COMMENT "",
  `min` varchar(65530) NOT NULL COMMENT "",
  `update_time` datetime NOT NULL COMMENT ""
) ENGINE=OLAP 
UNIQUE KEY(`table_id`, `column_name`, `db_id`)
COMMENT "OLAP"
DISTRIBUTED BY HASH(`table_id`, `column_name`, `db_id`) BUCKETS 10 
PROPERTIES (
"replication_num" = "2",
"in_memory" = "false",
"storage_format" = "DEFAULT"
);
#5

一开始show之后是这个表，于是我就看了下这个表的建表语句，发现副本数是1，然后看了下源码，发现如果副本是1就会报这个错误，我就把这个表drop掉，然后设置副本为2重新建表，但日志依旧刷，再show数据块发现表明已经为null了，所以您说的这个操作我已经做过了，没啥变化。

#6

SHOW PROC ‘/dbs/10002/12750/partitions/12749/12751/12758’：
1064 - Table[12750] does not exist, Time: 0.005000s

#7

看下10002是哪个db？另外期间有重启过fe和be没

#8

DBName：default_cluster:statistics,期间重启过多次FE，BE，还是没有变化。

#9

@U_1635841099034_9498
首先，打backend [11001] invalid situation. tablet[12752] has few replica[1], replica num setting is [1]，是因为对应的11001的be挂了，可以show backends看看有没有11001对应be？是不是DROP过这个be？

其次，可以直接把这个_statistics_这个库drop掉，过段时间会自动重建，不用手动建。这个表会自动根据你的be数目写副本数

还有，就是看日志上，后面insert into失败看上去好像也是因为这个表好像并没有被删掉

#10

11001对应的be没问题，我drop库试试吧

#11

最后哪里出了问题

京ICP备2022026421号-1