loop compact error

[chenbt-hz]

Is this a regression?

Yes

Description

pika在正常导数期间突然异常，发现某个rocksdb日志报错后无法手动执行compact，但监控大盘显示一直在compact

2025/07/10-06:04:09.826135 139631358109440 [db/db_impl/db_impl_files.cc:387] [JOB 394] Tried to delete a non-existing file /app/pika/pika-9224/db/db0/0/001055.log type=0 #1055 -- IO error: No such file or directory: while unlink() file: /app/pika/pika-9224/db/db0/0/001055.log: No such file or directory

类似问题：#1523

手动执行compact后，显示ok，但是info查看仍显示is_compact:No

但是监控大盘一直显示compact running中

Please provide a link to a minimal reproduction of the bug

No response

Screenshots or videos

No response

Please provide the version you discovered this bug in (check about page for version information)

Version：4.0.2

Anything else?

No response

[chenbt-hz]

@wangshao1 少一大佬能否帮忙看下？这种情况有没有修复办法？

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

@wangshao1 Can you help me see it? Is there a way to fix this situation?

[chenbt-hz]

fix：
根据之前的LOG日志，一直在反复执行L5层的compact。执行info keyspace 1后，开始触发L6层compact然后正常执行完毕。

后续手动执行compact，显示is_compact:Yes，后续观察问题实例暂时没重复异常。
问题修复

[chenbt-hz]

探索

1.问题实例执行info keyspace 1后，可以保持一段时间的正常； 没问题的实例执行info keyspace 1后，反而有概率出现相同bug，且重复执行info keyspace 1 也无法恢复了。
"job": 481, "event": "compaction_started", "compaction_reason": "ManualCompaction", "files_L5": [1783, 1784], "files_L6": [1749, 1754, 1758, 1763, 1767, 1771, 1775, 1778, 1750, 1753, ...], "score": -1, "input_data_size": 4103137151, "oldest_snapshot_seqno": -1}其中一个或多个文件不存在

2.对比Rocksdb日志：
异常时触发的compact任务操作的文件往往是不存在的文件；
并且日志不同：
正常执行时LOG日志：
Manual compaction from level-0 to level-6 from (begin) .. (end); will stop at (end)

异常执行时LOG日志【key已经作处理，仅作参考】：

[default] Manual compaction from level-0 to level-5 from '00000000000000003138372D4131425F4F4E4549445F4130313A2B2B557D775168504A73374B6E31573455735538575344684146536B597A35490000A0E7FDF197010000492D346363656539366337643331316237343034564564564564566234234226162373436320100000000000000000000000000000' seq:72057594037927935, type:22 .. '00000000000000007234382D4130315F4F4E4549445F4130312D7A7A704B6A4E486F597550507A7770726E69486E476B74636D2B854G37784B6A0 2025/07/10-11:01:19.455021 139939744315136 [db/compaction/compaction_job.cc:2071] [default] [JOB 483] Compacting 1@0 files to L5, score -1.00

PikaServer::AutoCompactRange()逻辑错误

#2816 增加了

if (g_pika_conf->compaction_strategy() == PikaConf::FullCompact) {
  DoSameThingEveryDB(TaskType::kCompactAll);
} else if (g_pika_conf->compaction_strategy() == PikaConf::OldestOrBestDeleteRatioSstCompact) {
  DoSameThingEveryDB(TaskType::kCompactOldestOrBestDeleteRatioSst);
}```

这个版本会在每次调用DoTimingTask()（通常每5秒一次）时检查策略并可能触发压缩可能导致连续的Manual compaction操作。  


原代码设置为Full-compact参数后，只要一导数立刻出发全量compact，后续修改一下代码初步测试不再会立刻触发压缩。

```cpp
struct timeval strategy_now;
gettimeofday(&strategy_now, nullptr);
// 处理基于策略的压缩，增加时间间隔控制，间隔时间（半小时）
if (last_strategy_compact_time_.tv_sec == 0 || 
  strategy_now.tv_sec - last_strategy_compact_time_.tv_sec >= 1800) {

  // 更新上次策略压缩时间
  gettimeofday(&last_strategy_compact_time_, nullptr);
  
  if (g_pika_conf->compaction_strategy() == PikaConf::OldestOrBestDeleteRatioSstCompact) {
    LOG(INFO) << "[Strategy]schedule OldestOrBestDeleteRatioSst, interval: 30 mins";
    DoSameThingEveryDB(TaskType::kCompactOldestOrBestDeleteRatioSst);
    }
  }