Database Backend Configuration
Backend choice
First of all, there is a choice between many backends :
Let’s see what are the best practice when using each of the existing backends.
MDB
MDB is using a single file to store every elements injected into the part of the DIT using this backend. This file has a fixed size, which is defined by olcDbMaxsize. This parameter can be changed dynamically when using cn=config (but not when using the static slapd.conf configuration file).
There are a few other knows one can play with to modify the way data are written on disk. Typically, writes can be deferred, which might improve the performances, at the risk of losing modifications (but no matter what, the base will remain consistent).
Most of the time, it’s just enough to define the correct file size (ie, big enough to store every entry and every index).
Initial size definition
This is the very first decision to make. It’s painful to have to resize the database when in production - ie, when it’s too late !-.
Rule of thumb : assuming the LDIF file containing the data to inject has a size of S, then the MDB size could be initially set to twice this size (2 x S). This will be highly dependent on how many indexes that are going to be created, especially substring indexes.
This is a very rough estimation, but at least you will be able to start with a decent size, most of the time. If you aren’t able to inject the full data, you can increase the size - doubling it, for instance - and restart the injection. At some point, you should be ok.
Now, you have to imagine what can happen in the next few years, depending on how frequently you update the data modifications or additions -. One way to get some insights about your database is to use mdb_stat.
TODO : Describe how mdb-stat works and explain its output.
LDIF
The LDIF backend is critical to OpenLDAP itself. The configuration
(cn=config), accessLog (cn=accessLog), and
sessionLog (cn=sessionlog) are all LDIF databases created
and maintained by slapd.
TODO: MOAR
LDAP
SQL
The SQL backend has suffered from years of lack of attention. A new contributor is trying to generate interest in the community to bring it up to date. For the moment, it should be considered EXPERIMENTAL. If you are interested, work with it. You very well may find it satisfactory.
Symas does not recommend the SQL backend for high-performance, high-availability use. It does offer an intriguing option for LDAP access to existing SQL data where the actual maintenance of the data is done by native SQL processes.
TODO: MOAR