ScyllaDB单节点cache.artists_bridge表无法访问且数据文件丢失求助

核心矛盾定位 #

你的问题本质是Scylla元数据与实际文件系统状态不一致：nodetool tablestats显示表存在8个SSTable、958MB数据，但实际数据目录仅保留预删除快照（pre-drop-xxxx），没有任何SSTable文件。这直接导致查询找不到数据超时，监控也无法抓取到表的真实状态。

根因推测 #

目录中的pre-drop-1747314122021快照是Scylla执行DROP TABLE时自动创建的恢复快照，说明该表曾触发过删除操作，但由于异常（比如IO中断、进程崩溃、磁盘权限问题）导致删除流程未完成：元数据未彻底清理，但实际SSTable文件已被删除，最终出现“幽灵表”状态。

排查与修复步骤 #

1. 验证元数据状态

   • 执行CQL查询确认系统元数据：

     SELECT * FROM system_schema.tables WHERE keyspace_name='cache' AND table_name='artists_bridge';
     SELECT * FROM system_schema.columns WHERE keyspace_name='cache' AND table_name='artists_bridge';
     

   • 如果查询返回结果，说明元数据残留；如果无结果，说明tablestats读取的是缓存的旧数据。

2. 恢复数据（若需保留）

   • 先创建与原表结构完全一致的空表：

     CREATE TABLE cache.artists_bridge (
         artist_id text PRIMARY KEY,
         global_artist_id text
     );
     

   • 停止对该表的所有查询请求后，执行快照恢复：

     nodetool restore cache artists_bridge pre-drop-1747314122021
     

   • 恢复完成后，用nodetool refresh cache artists_bridge刷新表状态，再验证查询是否正常。

3. 清理残留状态（若无需数据）

   • 尝试彻底删除表：

     DROP TABLE IF EXISTS cache.artists_bridge;
     

   • 如果执行失败或tablestats仍能查到该表，重启Scylla服务后再次执行删除操作，确保元数据彻底清理。

4. 深挖异常原因

   • 查看Scylla专属日志（默认路径/var/log/scylla/），搜索artists_bridge或drop table关键词，排查删除操作时是否出现IO错误、权限异常或进程崩溃记录。
   • 检查数据目录权限：确认/mnt/data/data/及其子目录的所有者是scylla用户，避免因权限不足导致文件操作失败。

预防措施 #

• 升级Scylla版本：3.0.8是较老旧的版本，存在不少元数据一致性相关的已知bug，建议升级到4.x或5.x系列的稳定版。
• 只读表定期校验：对只读表定期执行nodetool verify cache artists_bridge，检查SSTable完整性；小表可定期执行全表扫描确认可访问性。
• 监控磁盘与操作：确保Scylla数据目录磁盘空间充足，监控删除/修改表结构的操作日志，避免在高负载或磁盘异常时执行此类操作。

内容的提问来源于stack exchange，提问作者Killian G.