YugabyteDB手动执行刷盘操作为何无法删除全部WAL文件？

• 操作覆盖范围存在偏差：flush_all_tablets仅会触发目标tserver节点上当前承载的leader角色tablet的memtable落盘流程，不会对同节点上的follower角色tablet强制执行刷盘。如果目标表的部分tablet副本在该节点处于follower状态，对应副本产生的WAL不会被本次操作触发清理，会保留到对应leader副本完成刷盘、Raft日志同步位点推进后，才会进入待清理队列。
• WAL保留窗口的默认策略限制：系统不会在flush操作完成后立刻物理删除WAL文件，WAL回收需要同时满足两个前置条件：一是WAL覆盖的所有写入记录已成功落盘为SST文件，二是WAL的产生时间距当前时间不小于--wal_retention_secs配置值（默认30分钟）。即使刷盘全部完成，只要文件仍处于保留窗口内，就会被强制留存，不会因为对应SST已生成就执行删除。
• 下游消费者的位点滞后锁定WAL：如果节点上存在长时间运行的全表扫描任务、备份流程、已配置的CDC数据同步流，这些组件会持续持有WAL的最小可读取位点。哪怕WAL对应的写入内容已经全部落盘为SST，只要消费者的读取位点没有推进到残留WAL的结束偏移量，系统就不会删除对应WAL文件，避免消费者读取时出现数据缺失报错。
• 部分tablet的刷盘任务实际未成功执行：yb-ts-cli返回操作完成的反馈，不代表所有选中的tablet都顺利走完了flush流程。如果部分tablet在刷盘过程中出现临时IO故障、Memtable写入错误、Raft leader切换导致的流程中断，这些tablet上的WAL会因为对应memtable内容没有成功落盘，持续保留在磁盘路径下。可通过执行yb-ts-cli --server_address=<目标节点地址> list_tablets查看目标表的所有tablet运行状态，结合tserver运行日志定位失败的刷盘任务。
• WAL后台清理线程运行阻塞：tserver内部负责WAL回收的后台线程如果出现锁竞争、磁盘IO卡顿、元数据操作超时的情况，会暂停WAL清理流程。此时即使所有WAL清理的前置条件都已满足，对应文件也会暂时滞留在存储路径下，直到后台线程恢复正常运行后才会被批量回收。

内容的提问来源于stack exchange，提问作者dh YB