Embedded Cassandra 3.11.7突发挂起及文件占用问题排查求助

核心矛盾梳理 #

应用侧从08:44起无法连接嵌入式Cassandra，报com.datastax.driver.core.exceptions.NoHostAvailableException，但Cassandra日志正常输出至14:47；停止时出现java.nio.file.FileSystemException提示临时目录.toDelete文件被占用。结合环境信息，重点从文件锁阻塞、线程状态、网络/驱动兼容性三个方向排查。

1. 排查.toDelete文件占用与Flush操作的关联 #

每4小时执行的nodetool flush会触发SSTable归档，Cassandra会将待删除的SSTable路径写入.toDelete文件，等待后续清理。Windows下文件锁机制严格，第三方进程锁定该文件会导致Cassandra内部线程阻塞，进而无法响应连接请求：

• 定位占用进程：使用Process Explorer工具，点击Find→Find Handle or DLL，输入.toDelete文件名，直接定位到占用该文件的进程（常见为杀毒软件、Windows索引服务、备份工具）。
• 验证Flush阻塞影响：检查08:44前后的Flush执行日志（若有），确认是否在Flush后出现连接异常；将Flush操作临时暂停，观察应用连接是否恢复，以此验证关联关系。
• 调整目录配置：将Embedded Cassandra的数据目录、临时目录（java.io.tmpdir）迁移至非系统盘（如D盘），避免Windows系统进程的默认监控。

2. 分析Cassandra内部线程状态 #

Cassandra进程未崩溃但无法响应连接，大概率存在线程死锁或长时间停顿：

• 生成线程快照：在应用无法连接的时间段，执行jstack <SpringBoot进程PID>（嵌入式Cassandra与SpringBoot同进程），搜索deadlock关键字排查死锁；重点关注MemtableFlushWriter、CompactionExecutor等与Flush/清理相关的线程状态。
• 检查GC停顿：添加JVM参数-XX:+PrintGCDetails -XX:+PrintGCTimeStamps收集GC日志，查看08:44左右是否发生Full GC导致超过10秒的停顿，使得Cassandra无法响应驱动连接请求。

3. 验证网络与驱动兼容性 #

• 端口与连接检查：执行netstat -ano | findstr 9042（默认Cassandra端口），确认端口仅被SpringBoot进程持有，无其他进程占用；检查Windows防火墙是否临时拦截本地127.0.0.1的连接请求。
• 驱动版本对齐：SpringBoot 2.2.2默认依赖的Cassandra Driver版本为3.7.x，与Embedded Cassandra 3.11.7存在小版本协议差异。将SpringBoot的spring-data-cassandra依赖升级至与Cassandra版本匹配的3.11.x，重新测试连接。

4. 嵌入式Cassandra Windows兼容性修复 #

Cassandra 3.11.7在Windows环境下存在文件系统相关的已知问题：

• 修改Embedded Cassandra配置，关闭自动清理功能（auto_sstable_compaction: false），手动执行清理操作，避免自动清理时触发文件锁冲突。
• 确保JDK 1.8为官方Oracle或OpenJDK版本，避免第三方JDK的文件系统实现差异导致问题。

内容的提问来源于stack exchange，提问作者junsung kang