Corruption: Can't access /1270450.sst: IO error: while stat a file for size: /xx/1270450.sst: No such file or directory

[dgpp-programer]

hello, my main process opens the rocksdb database by rocksdb::DB::Open(), while another process opens it by rocksdb::DB::OpenForReadOnly. When opening it, an error message :
Corruption: Can't access /1270450.sst: IO error: while stat a file for size: /xx/1270450.sst: No such file or directory

The reason is that the main process is compaction and has deleted these SST files.

Is there any way to avoid this issue?
rocksdb version: v5.10.3.
Will the new version have this problem?

[Dorence]

Normally, readonly db opens all SST files, files are still available even if primary db deletes. Do you set max_open_files to -1 for readonly db? Or maybe too much opened files that exceeds system limit (port::GetMaxOpenFiles()).

[dgpp-programer]

Normally, readonly db opens all SST files, files are still available even if primary db deletes. Do you set max_open_files to -1 for readonly db? Or maybe too much opened files that exceeds system limit (port::GetMaxOpenFiles()).

Thanks for your reply.
The max_open_files already -1(default value is -1), and the opened files have not exceeded the system limit. By observing the rocksdb logs, it can be seen which files cannot be found when each Open fails. Then, by checking the rocksdb logs in primary db, which happened to be performing compaction, these files were deleted.
I speculate that the readonly db, after loading the manifest, was traversing and opening all SST files when the primary db had just completed a round of compaction and deleted some files.
I understand that Rocksdb may not be able to detect which SST files are being occupied by other processes?