Chapter 5. Tuning Transaction Logging

Every Directory Server contains a transaction log which writes operations for all the databases it manages. Whenever a directory database operation such as a modify is performed, the server creates a single database transaction for all of the database operations invoked as a result of that LDAP operation. This includes both updating the entry data in the entry index file and updating all of the attribute indexes. If all of the operations succeed, the server commits the transaction, writes the operations to the transaction log, and verifies that the entire transaction is written to disk. If any of these operations fail, the server rolls back the transaction, and all of the operations are discarded. This all-or-nothing approach in the server guarantees that an update operation is atomic. Either the entire operation succeeds permanently and irrevocably, or it fails.
Periodically, the Directory Server (through internal housekeeping threads) flushes the contents of the transaction logs to the actual database index files and checks if the transaction logs require trimming.
If the server experiences a failure, such as a power outage, and shuts down abnormally, the information about recent directory changes is still saved by the transaction log. When the server restarts, the directory automatically detects the error condition and uses the database transaction log to recover the database.
Although database transaction logging and database recovery are automatic processes that require no intervention, it can be advisable to tune some of the database transaction logging attributes to optimize performance.

Warning

The transaction logging attributes are provided only for system modifications and diagnostics. These settings should be changed only with the guidance of Red Hat Technical Support. Setting these attributes and other configuration attributes inconsistently may cause the directory to be unstable.

5.1. Moving the Database Directory to a Separate Disk or Partition

To achieve higher performance, store the directory server databases and transaction log on a fast drive, such as a nonvolatile memory express (NVMe) drive or an SSD.
For example, if you already run a Directory Server instance and want to mount the /dev/nvme0n1p1 partition to the /var/lib/dirsrv/slapd-instance_name/db/ directory:
  1. Stop the instance:
    # systemctl stop dirsrv@instance_name
  2. Mount the /dev/nvme0n1p1 partition to a temporary directory. For example:
    # mount /dev/nvme0n1p1 /mnt/
  3. Copy the content of the /var/lib/dirsrv/slapd-instance_name/db/ directory to the temporary mount point:
    # mv /var/lib/dirsrv/slapd-instance_name/db/* /mnt/
  4. Unmount the temporary directory:
    # umount /mnt/
  5. If /var/lib/dirsrv/slapd-instance_name/db/ is also a separate mount point, unmount the directory:
    # umount /var/lib/dirsrv/slapd-instance_name/db/
  6. Update the /etc/fstab file to mount the /dev/nvme0n1p1 partition automatically to /var/lib/dirsrv/slapd-instance_name/db/ when the system boots. For details, see the corresponding section in the Red Hat System Administrator's Guide.
  7. Mount the file system. If you added the entry to /etc/fstab:
    # mount /var/lib/dirsrv/slapd-instance_name/db/
  8. If SELinux is running in enforcing mode, restore the SELinux context:
    # restorecon -Rv /var/lib/dirsrv/slapd-instance_name/db/
  9. Start the instance:
    # systemctl start dirsrv@instance_name