Neo4j 3.3.3企业版事务日志无法修剪，磁盘空间耗尽求助

针对你遇到的事务日志无限制增长、已配置保留策略和检查点但无效的情况，结合Neo4j 3.3.x的核心机制，给你梳理几个关键排查和修复步骤：

• 确认检查点是否正常触发
  事务日志只有在检查点完成后才能被安全修剪，你设置了dbms.checkpoint=volumetric，但需要验证检查点是否真的在定期运行：

  1. 打开debug.log，搜索关键词Checkpoint triggered by，查看是否有定期生成的日志条目（比如类似Checkpoint triggered by volumetric threshold）。
  2. 如果检查点触发频率太低，调整dbms.checkpoint.volumetric.size参数（默认是100M），比如改为50M——当写入量达到这个阈值时就触发检查点，这样能更频繁地让旧日志进入可修剪状态。

• 验证事务日志保留策略的生效逻辑
  你设置的dbms.tx_log.rotation.retention_policy=20G size是指所有事务日志的总大小上限，但要注意几个细节：

  1. 单个事务日志文件的大小由dbms.tx_log.rotation.size控制（默认100M），如果这个值设置过大，即使总容量没到20G，单个大文件也会占用大量空间。
  2. 确保没有同时配置多个保留策略（比如同时设置size和time），否则会取最严格的那个，可能导致日志无法被修剪。

• 排查是否有进程阻止日志修剪
  某些后台进程会锁定事务日志，导致无法被删除：

  1. 检查是否有在线备份进程在运行或卡住——Neo4j在线备份会保留事务日志直到备份完成，如果备份中断或长时间未完成，日志会持续累积。
  2. 确认没有未完成的长事务——长事务会阻止检查点推进，进而无法修剪旧日志，可以用CALL dbms.listTransactions()查看当前运行的事务，是否有长时间未结束的。

• 手动触发检查点与日志修剪
  如果自动机制失效，可以手动触发来验证：

  1. 执行Cypher命令：CALL db.checkpoint()，强制触发检查点。
  2. 查看debug.log中是否出现Log pruning completed的条目，同时检查data/dbms/tx_log/neo4j目录下的日志文件是否被清理。
  3. 如果手动操作后日志被成功修剪，说明自动检查点的触发条件需要调整（比如调小dbms.checkpoint.volumetric.size）。

• 检查版本已知问题并考虑补丁升级
  Neo4j 3.3.3存在一些已知的日志修剪相关bug，比如某些场景下检查点完成后日志未被标记为可删除。建议升级到3.3.x系列的最新补丁版本（比如3.3.9），这些版本修复了不少此类稳定性问题。

内容的提问来源于stack exchange，提问作者Martin Preusse