磁盘空间耗尽导致Neo4j写入中断，是数据库损坏的常见原因，你遇到的日志里提到的LogPosition{logVersion=250, byteOffset=198709181}，说明事务日志在写入到这个位置时被打断了。下面是我整理的实操修复步骤，按顺序来：

第一步：先搞定磁盘空间！ #

这是最基础的前提——先清理磁盘，腾出至少几个G的可用空间（如果数据库比较大，得多腾点），不然后续修复操作也会因为空间不足失败。

第二步：立刻备份现有数据！ #

别直接碰原数据库文件，万一操作失误就彻底没救了。找到你的Neo4j数据目录（默认是data/databases/graph.db，如果自定义过路径就找你自己的），把整个目录复制到安全的地方：

cp -r data/databases/graph.db /path/to/safe/location/graph.db.backup

第三步：用Neo4j自带修复工具尝试修复 #

Neo4j 3.3.x提供了neo4j-admin repair命令，专门用来修复损坏的数据库文件：

1. 先确保Neo4j已经停止（如果它还在反复尝试启动）：

   neo4j stop
   

2. 运行修复命令（注意：这个命令会修改原数据库文件，所以一定要先做好备份！）：

   neo4j-admin repair --database=graph.db
   

3. 修复完成后，尝试启动Neo4j：

   neo4j start
   

第四步：手动截断损坏的事务日志（如果修复工具没用） #

如果上面的方法没起效，我们可以针对报错里提到的损坏日志文件动手：

1. 进入数据库的事务日志目录，默认路径是data/databases/graph.db/transaction_logs，进去看看：

   cd data/databases/graph.db/transaction_logs
   

2. 找到日志文件log.250（对应报错里的logVersion=250），先查看它的实际大小：

   ls -lh log.250
   

   如果文件大小小于报错里的198709181字节（约189MB），说明这个日志文件确实被截断损坏了。
3. 删除这个损坏的日志文件，以及所有版本号比250高的日志文件（因为事务日志是顺序写入的，后面的日志依赖前面的，前面坏了后面的也没用了）：

   rm log.250 log.251 log.252  # 替换成实际存在的高版本日志文件
   

4. 再次尝试运行neo4j-admin repair，然后启动Neo4j。

第五步：尝试导出并恢复数据（如果以上都失败） #

如果数据库损坏比较严重，试试用neo4j-admin dump导出数据——即使数据库无法启动，dump工具通常能导出大部分可用数据：

1. 导出损坏的数据库到dump文件：

   neo4j-admin dump --database=graph.db --to=/path/to/backup/graph.db.dump
   

2. 创建一个新的数据库，把dump文件导入进去：

   neo4j-admin load --from=/path/to/backup/graph.db.dump --database=new-graph.db
   

3. 修改Neo4j配置文件neo4j.conf，把dbms.active_database的值改成new-graph.db，然后启动Neo4j。

最后说点预防措施，避免再踩坑 #

• 给服务器加个磁盘空间监控，设置告警，一旦空间不足立刻收到通知；
• 定期备份数据库，比如每周用neo4j-admin dump做一次全量备份，或者开启Neo4j的自动备份功能；
• 在neo4j.conf里配置事务日志的保留策略，比如dbms.tx_log.rotation.retention_policy=7 days，避免日志文件无限累积占满磁盘。

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