Ubuntu 20.04上的Neo4j 4.2.1社区版本
我管理的数据库未能从此错误开始:
"Caused by: java.lang.RuntimeException: java.lang.RuntimeException: Error reading transaction logs, recovery not possible. To force the database to start anyway, you can specify 'unsupported.dbms.tx_log.fail_on_corrupted_log_files=false'. This will try to recover as much as possible and then truncate the corrupt part of the transaction log. Doing this means your database integrity might be compromised, please consider restoring from a consistent backup instead."
如果我从昨天回滚到服务器实例,数据库运行良好,但它将经历如下的恢复步骤:
2022-07-10 12:21:23.825+0000 INFO [o.n.k.d.Database] [neo4j/2443e357] Recovery required from position LogPosition{logVersion=0, byteOffset=191545629}
2022-07-10 12:21:27.676+0000 INFO [o.n.k.r.Recovery] [neo4j/2443e357] 10% completed
2022-07-10 12:21:28.578+0000 INFO [o.n.k.r.Recovery] [neo4j/2443e357] 20% completed
2022-07-10 12:21:29.715+0000 INFO [o.n.k.r.Recovery] [neo4j/2443e357] 30% completed
2022-07-10 12:21:31.078+0000 INFO [o.n.k.r.Recovery] [neo4j/2443e357] 40% completed
2022-07-10 12:21:32.140+0000 INFO [o.n.k.r.Recovery] [neo4j/2443e357] 50% completed
2022-07-10 12:21:32.709+0000 INFO [o.n.k.i.a.i.IndexingService] [neo4j/2443e357] IndexingService.init: indexes not specifically mentioned above are ONLINE
2022-07-10 12:21:37.360+0000 INFO [o.n.k.r.Recovery] [neo4j/2443e357] 60% completed
2022-07-10 12:21:39.550+0000 INFO [o.n.k.r.Recovery] [neo4j/2443e357] 70% completed
2022-07-10 12:21:40.971+0000 INFO [o.n.k.r.Recovery] [neo4j/2443e357] 80% completed
2022-07-10 12:21:42.104+0000 INFO [o.n.k.r.Recovery] [neo4j/2443e357] 90% completed
2022-07-10 12:21:43.128+0000 INFO [o.n.k.r.Recovery] [neo4j/2443e357] 100% completed
2022-07-10 12:21:43.151+0000 INFO [o.n.k.d.Database] [neo4j/2443e357] Recovery completed. 195143 transactions, first:98943, last:294085 recovered, time spent: 18s 577ms
但是,这显然不是100%确定的,因为如果我尝试使用sudo neo4j-admin dump --database=neo4j --to=~/运行备份,就会得到以下错误:
Active logical log detected, this might be a source of inconsistencies.
Please recover database before running the dump.
To perform recovery please start database and perform clean shutdown.
启动和关闭都没什么区别。
在我们的保留期内的所有备份都有这个问题。
我们每天执行一个脚本,执行大量删除和插入数据库。当我在工作实例上运行它并重新启动数据库时,数据库无法重新启动,并且我得到了我第一次列出的错误。
因此,事务日志中的损坏似乎已经持续了一段时间,运行这批删除和插入“将其推到边缘”,使其失败。顺便说一句,这个脚本已经每天运行了两年,没有任何问题,所以我相信它不是脚本本身造成的问题。
在运行脚本之前,我尝试过设置dbms.tx_log.rotation.retention_policy=keep_none,虽然失败的开始错误变成了:
Caused by: java.lang.RuntimeException: org.neo4j.exceptions.UnderlyingStorageException: No check point found in any log file from version 1 to 2
我还尝试删除事务日志文件作为一种绝望的措施。像预期的那样打破了一切。
我正在运行社区版本,我的备份是EC2服务器实例,所以我不认为我需要事务日志功能。
如何修复或删除事务日志?谢谢。
发布于 2022-07-10 14:55:44
旧事务日志无法安全存档或删除。因此,您可以使用dbms.directories.transaction.logs.root来更改Neo4j存储事务日志的根位置。
或者,如果问题可能与内存有关,您可以控制逻辑日志将由dbms.tx_log.rotation.size自动旋转的文件大小。
https://stackoverflow.com/questions/72928524
复制相似问题