YugabyteDB YSQL销毁常规DB失败报LOCK文件不存在IO错误

这类报错绝大多数场景下可直接忽略，不会影响集群正常业务运行。

从日志代码位置和报错信息可以定位，问题出在tserver后台清理失效tablet的RocksDB实例流程：

• 集群执行删表、tablet副本重平衡、失效副本回收操作时，会触发节点本地旧tablet数据目录的销毁流程
• 旧版本YugabyteDB的清理逻辑带重试机制：第一次清理已经把目标tablet目录（含目录下的LOCK锁文件）完整删除后，后续重试任务没有提前判断目录是否存在，直接尝试打开目录下的LOCK文件执行销毁操作，就会抛出No such file or directory的IO错误
  你已经确认磁盘、网络运行正常，psql侧create/drop/select/update/insert全操作可正常执行，足以说明报错和正在提供服务的活跃tablet无关，仅出现在后台垃圾回收的冗余重试路径上，不会损坏业务数据，也不会中断正常服务。

如果需要彻底排除风险，可做以下检查：

• 核对文件路径：任选日志中打印的tablet目录路径，查看上层table-xxx目录下是否已经不存在对应的tablet-xxx子目录，如果目录确实已被删除，完全符合冗余重试的报错特征
• 校验副本状态：执行yb-admin -master_addresses <集群master地址列表> list_tablets_for_server <当前tserver的UUID>，确认日志中打印的几个tablet ID已经不在当前节点的服务副本列表中，说明这些tablet已经完成迁移/删除流程，属于正常清理范畴
• 如果嫌这类ERROR日志刷屏干扰排查，可升级到已修复该日志问题的稳定版本，新版本会提前判断待清理目录是否存在，目录已删除的场景不会再打印ERROR级别的冗余日志。

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