The transaction logs record all write operations in the database. They are the "source of truth" in scenarios where the database needs to be recovered. The transaction logs can be used to provide differential backups, as well as for cluster operations. For any given configuration, at least the latest non-empty transaction log is kept.
Each database keeps its own directory with transaction logs.
The root directory where the transaction log folders are located is configured by
The transaction log has nothing to do with log monitoring.
The transaction logs record all write operations in the database. This includes additions or modifications to data, as well as the addition or modification of any indexes or constraints.
The transaction logs are the "source of truth" in scenarios where the database needs to be recovered.
The transaction logs are used for providing differential backups, as well as for cluster operations.
For any given configuration, at least the latest non-empty transaction log will be kept.
An overview of configuration settings for transaction logging:
|The transaction log configuration||Default value||Description|
Root location where Neo4j will store transaction logs for configured databases.
Specify if Neo4j should try to preallocate logical log file in advance.
Make Neo4j keep the logical transaction logs for being able to back up the database. Can be used for specifying the threshold to prune logical logs after.
Specifies at which file size the logical log will auto-rotate.
Minimum accepted value is
The retention and rotation policies for the Neo4j transaction logs, and how to configure them.
By default, transaction logs for a database are located at <neo4j-home>/data/transactions/<database-name>. Each database keeps its own directory with transaction logs.
The root directory where those folders are located is configured by
For maximum performance, it is recommended to configure transaction logs to be stored on a dedicated device.
Log rotation is configured using the parameter
By default, log switches happen when log sizes surpass 250 MB.
Manually deleting transaction log files is not supported.
You can control the number of transaction logs that Neo4j keeps using the parameter
It is set to
2 days by default, which means Neo4j keeps logical logs that contain any transaction committed within 2 days.
The configuration is dynamic, so if you need to update it, you do not have to restart Neo4j for the change to take effect.
Other possible values are:
keep_all— keep transaction logs indefinitely.
This option is not recommended due to the effectively unbounded storage usage. Old transaction logs cannot be safely archived or removed by external jobs since safe log pruning requires knowledge about the most recent successful checkpoint.
keep_none— keep only the most recent non-empty log.
Log pruning is called only after checkpoint completion to ensure at least one checkpoint and points to a valid place in the transaction log data. In reality, this means that all transaction logs created between checkpoints will be kept for some time, and only after a checkpoint, the pruning strategy will remove them. For more details on how to speed up checkpointing, see Log pruning. To force a checkpoint, run the procedure
This option is not recommended in production Enterprise Edition environments, as differential backups rely on the presence of the transaction logs since the last backup.
<number><optional unit> <type>where valid units are
G, and valid types are
Table 1. Types that can be used to control log retention Type Description Example
The number of the most recent logical log files to keep.
Max disk size to allow log files to occupy.
"300M size" or "1G size".
The number of transactions to keep.
"250k txs" or "5M txs".
Keep logs that contain any transaction committed within N hours from the current time.
Keep logs that contain any transaction committed within N days from the current time.
"50 days"Example 1. Configure log retention policy
This example shows some different ways to configure the log retention policy.
Keep transaction logs indefinitely:
Keep only the most recent non-empty log:
Keep logical logs that contain any transaction committed within 30 days:
Keep logical logs that contain any of the most recent 500 000 transactions:
Transaction log pruning refers to the safe and automatic removal of old, unnecessary transaction log files. The transaction log can be pruned when one or more files fall outside of the configured retention policy.
Two things are necessary for a file to be removed:
The file must have been rotated.
At least one checkpoint must have happened in a more recent log file.
Observing that you have more transaction log files than you expected is likely due to checkpoints either not happening frequently enough, or taking too long. This is a temporary condition and the gap between the expected and the observed number of log files will be closed on the next successful checkpoint. The interval between checkpoints can be configured using:
|Checkpoint configuration||Default value||Description|
Configures the time interval between checkpoints.
Configures the transaction interval between checkpoints.
If your goal is to have the least amount of transaction log data, it can also help to speed up the checkpoint process itself.
The configuration parameter
db.checkpoint.iops.limit controls the number of IOs per second the checkpoint process is allowed to use.
Setting the value of this parameter to
-1 allows unlimited IOPS, which can speed up checkpointing.
Disabling the IOPS limit can cause transaction processing to slow down a bit. For more information, see Checkpoint IOPS limit.
Was this page helpful?