排查过程
A：
以下操作都需要在leader fe上执行
首先确认当前报错tablet的所在be 的副本
show tablet $tablet_id
接着执行上一步返回的detailcmd命令
mysql> SHOW PROC '/dbs/141667/1572816827/partitions/1572815451/1572873803/1572929616'\G;
*************************** 1. row ***************************
ReplicaId: 1572929617
BackendId: 11002
Version: 4268
VersionHash: 0
LstSuccessVersion: 4268
LstSuccessVersionHash: 0
LstFailedVersion: -1
LstFailedVersionHash: 0
LstFailedTime: NULL
SchemaHash: -1
DataSize: 3837908
RowCount: 386698
State: NORMAL
IsBad: false
IsSetBadForce: false
VersionCount: 4
PathHash: -1
MetaUrl: http://xxx:8040/api/meta/header/1572929616
CompactionStatus: http://xxx:8040/api/compaction/show?tablet_id=1572929616&schema_hash=-1
IsErrorState: false
发现是4268，但是查询的是4251，这个一般是分区的VisibleVersion滞后导致，排查下分区的VisibleVersion
show partitions from db.table WHERE PartitionName = “xxx”;
发现确实分区的VisibleVersion只有4251，到这里怀疑应该是这个分区下面的部分tablet副本没有正常往前推进，
show tablet from db.table PARTITION (p20240828);
发现有一些副本的version是4250，发现还都是一个be，这个时候确认下其他副本中有没有version是最新的（4268）的，如果有，则把4250对应的副本 set bad（切记处理的tablet需要有正常的副本）
ADMIN SET REPLICA STATUS PROPERTIES("tablet_id" = "$tablet_id", "backend_id" = "$backendid", "status" = "bad");
处理完成后观察该分区的visibleversion是否正常往前推进
show partitions from db.table WHERE PartitionName = "xxx";
原理解析
starrocks 查询的时候，下发的版本是以 partition的visibleversion为准，比如partition的visibleversion为1001，那么就会下发该版本到tablet去查找。一般遇到version already been compacted可能的原因是partition的visibleversion落后于tablet的version，可能是该分区下有部分tablet副本publish卡了，但是有部分tablet副本publish正常版本还在往前推进，sr内部默认历史版本保留30分钟，超过后会GC掉，所以当分区下发的版本远小于tablet对应的版本的时候，就会出现version already been compacted的报错。
一般处理办法尝试把落后的tablet副本手动set bad，让从其他正常副本clone，进而保证分区的visibleversion向前推进。