lide-reed opened a new issue, #66051:
URL: https://github.com/apache/doris/issues/66051

   ### Search before asking
   
   - [x] I had searched in the 
[issues](https://github.com/apache/doris/issues?q=is%3Aissue) and found no 
similar issues.
   
   
   ### Version
   
   ## Summary
   
   On tables using **storage policy / cold data tiering** (cooldown to remote 
object storage such as S3/COS/HDFS) with **replication num >= 2**, cold data 
files on remote storage can be **permanently deleted while still being 
referenced** by the current (latest) cooldown metadata, after a **full clone** 
triggered by cluster topology changes (scale in/out, spec change, replica 
balance, BE restart, bad-disk replica repair).
   
   The result is a **dangling reference**: the tablet metadata still records 
the rowset as valid, but the corresponding `.dat` object is gone from remote 
storage. Queries then fail at `initialize storage reader` with `[NOT_FOUND] 
failed to get file size ... on remote`.
   
   This is a **latent, silent data-loss bug**. It is not specific to any single 
deployment.
   
   ## Affected versions / branches
   
   Verified by source inspection on the latest of each branch:
   
   | Branch | BE defect (reuse clone-source `cooldown_meta_id`) | FE defect (no 
null guard on `cooldown_meta_id`) | Path | Affected |
   |--------|:--:|:--:|------|:--:|
   | branch-2.1 | YES | YES | `be/src/olap/task/engine_clone_task.cpp` | 
**YES** |
   | branch-3.1 | YES | YES | `be/src/olap/task/engine_clone_task.cpp` | 
**YES** |
   | branch-4.1 | YES | YES | `be/src/storage/task/engine_clone_task.cpp` 
(relocated) | **YES** |
   | master     | YES | YES | `be/src/storage/task/engine_clone_task.cpp` 
(relocated) | **YES** |
   
   Note: 4.1/master only relocated the code from `be/src/olap/` to 
`be/src/storage/`; the defective logic is unchanged.
   
   
   ### What's Wrong?
   
   ## Summary
   
   On tables using **storage policy / cold data tiering** (cooldown to remote 
object storage such as S3/COS/HDFS) with **replication num >= 2**, cold data 
files on remote storage can be **permanently deleted while still being 
referenced** by the current (latest) cooldown metadata, after a **full clone** 
triggered by cluster topology changes (scale in/out, spec change, replica 
balance, BE restart, bad-disk replica repair).
   
   The result is a **dangling reference**: the tablet metadata still records 
the rowset as valid, but the corresponding `.dat` object is gone from remote 
storage. Queries then fail at `initialize storage reader` with `[NOT_FOUND] 
failed to get file size ... on remote`.
   
   This is a **latent, silent data-loss bug**. It is not specific to any single 
deployment.
   
   **问题**:启用冷热分层(降冷到对象存储)且副本数 ≥ 2 的表,在集群扩缩容/变配/副本均衡/BE 重启等触发**全量 clone** 
后,远端冷数据文件可能被**误删**,而当前最新的 cooldown 元数据仍在引用它 —— 形成**悬空引用**,查询报 `[NOT_FOUND] ... 
on remote`。这是一个**静默的数据丢失缺陷**。
   
   
   ### What You Expected?
   
   正常
   
   ### How to Reproduce?
   
   **触发特征**:删除滞后触发操作约 3–6h;**首次切主(term=0/1)即可触发**,无需多轮累积。
   
   ### Anything Else?
   
   _No response_
   
   ### Are you willing to submit PR?
   
   - [ ] Yes I am willing to submit a PR!
   
   ### Code of Conduct
   
   - [x] I agree to follow this project's [Code of 
Conduct](https://www.apache.org/foundation/policies/conduct)
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to