Backend Choice

Choosing the appropriate backend for OpenLDAP is critical for optimal performance and reliability. Below are best practices and considerations for each of the existing backends.

MDB

The MDB backend uses a single file to store all elements injected into the part of the Directory Information Tree (DIT) using this backend. This file has a fixed size, defined by olcDbMaxsize. This parameter can be changed dynamically when using cn=config but not when using the static slapd.conf configuration file.

Several parameters can be adjusted to modify how data is written to disk. For example, writes can be deferred to improve performance, though this comes with the risk of losing recent modifications. Regardless, the database will remain consistent.

Generally, it is sufficient to define the correct file size (i.e., large enough to store all entries and indexes).

Initial Size Definition

The initial size definition is a crucial first step. It is challenging to resize the database once it is in production.

Rule of thumb: If the LDIF file containing the data to inject has a size of S, the MDB size should initially be set to twice this size (2 x S). This rough estimation accounts for the number of indexes, especially substring indexes.

This approximation should help you start with a reasonable size. If the full data cannot be injected, increase the size (e.g., double it) and restart the injection. Eventually, this process should allow you to find an appropriate size.

Consider potential future changes based on how frequently data is updated or added. Tools like mdb_stat can provide insights into your database.

mdb_stat is a command-line utility for the LMDB (Lightning Memory-Mapped Database) that displays statistics and information about an LMDB environment. It provides details about the database's pages, tree structure, and overall size, helping users understand its layout and performance characteristics.

The output typically includes:

• Branch pages: Number of internal (non-leaf) pages.
• Leaf pages: Number of leaf pages storing key/data pairs.
• Overflow pages: Number of overflow pages used for large data items.
• Entries: Total number of key/data pairs in the database.
• Tree depth: Depth of the B-tree.
• Page size: Size of each database page.

These metrics help in assessing the database's efficiency and diagnosing issues.

LDIF 

Overview

The LDIF backend to slapd(8) is a basic storage backend that stores entries in text files in LDIF format, and exploits the filesystem to create the tree structure of the database. It is intended as a cheap, low performance easy to use backend.

When using the cn=config dynamic configuration database with persistent storage, the configuration data is stored using this backend. See slapd-config(5) for more information

include ./schema/core.schema
        database ldif
        directory ./ldif
        suffix "dc=suretecsystems,dc=com"
        rootdn "cn=LDIF,dc=suretecsystems,dc=com"
        rootpw LDIF

dn: dc=suretecsystems,dc=com
        objectClass: dcObject
        objectClass: organization
        dc: suretecsystems
        o: Suretec Systems Ltd

ldapadd -x -H ldap://localhost:9011 -f suretec.ldif -D "cn=LDIF,dc=suretecsystems,dc=c
        adding new entry "dc=suretecsystems,dc=com"

ls ./ldif
        dc=suretecsystems,dc=com.ldif

cat ldif/dc\=suretecsystems\,dc\=com.ldif
        dn: dc=suretecsystems
        objectClass: dcObject
        objectClass: organization
        dc: suretecsystems
        o: Suretec Systems Ltd.
        structuralObjectClass: organization
        entryUUID: 2134b714-e3a1-102c-9a15-f96ee263886d
        creatorsName: cn=LDIF,dc=suretecsystems,dc=com
        createTimestamp: 20080711142643Z
        entryCSN: 20080711142643.661124Z#000000#000#000000
        modifiersName: cn=LDIF,dc=suretecsystems,dc=com
        modifyTimestamp: 20080711142643Z

LDAP

Overview

The LDAP backend to slapd(8) is not an actual database; instead it acts as a proxy to forward incoming requests to another LDAP server. While processing requests it will also chase referrals, so that referrals are fully processed instead of being returned to the slapd client.

Sessions that explicitly Bind to the back-ldap database always create their own private connection to the emote LDAP server. Anonymous sessions will share a single anonymous connection to the remote server. For sessions bound through other mechanisms, all sessions with the same DN will share the same connection. This connection pooling strategy can enhance the proxy's efficiency by reducing the overhead of repeatedly making/breaking multiple connections. 

The ldap database can also act as an information service, i.e. the identity of locally authenticated clients is asserted to the remote server, possibly in some modified form. For this purpose, the proxy binds to the remote server with some administrative identity, and, if required, authorizes the asserted identity.

It is heavily used by a lot of other backends and overlays.

back-ldap Configuration

As previously mentioned, slapd-ldap(5) is used behind the scenes by many other Backends and Overlays. Some of them merely provide a few configuration directive themselves, but have available to the administrator the whole of the slapd-ldap(5) options. 

For example, the Translucent Proxy, which retrieves entries from a remote LDAP server that can be partially overridden by the defined database, has only four specific translucent- directives, but can be configured using any of the normal slapd-ldap(5) options. See slapo-translucent(5) for details.

Other overlays allow you to tag directives in front of a normal slapd-ldap(5) directive. For example, the slapo-chain(5) overlay does this:

"There are very few chain overlay specific directives; however, directives related to the instances of the ldap backend that may be implicitly instantiated by the overlay may assume a special meaning when used in conjunction with this overlay. They are described in slapd-ldap(5), and they also need to be prefixed by chain-."

You may have also seen the slapd-ldap(5) backend used and described in the Push Based Replication section of the guide.

It should therefore be obvious that the slapd-ldap(5) backend is extremely flexible and heavily used throughout the OpenLDAP Suite. 

The following is a very simple example, but already the power of the slapd-ldap(5) backend is seen by use of a uri list:

database ldap
suffix "dc=suretecsystems,dc=com"
rootdn "cn=slapd-ldap"
uri ldap://localhost/ ldap://remotehost ldap://remotehost2

The URI list is space or comma-separated. Whenever the server that responds is not the first one in the list, the list is rearranged and the responsive server is moved to the head, so that it will be first contacted the next time a connection needs be created.

This feature can be used to provide a form of load balancing when using Mirror mode replication.

SQL

The SQL backend has suffered from years of neglect. A new contributor is working to generate interest in the community to update it. For now, it should be considered EXPERIMENTAL. If you are interested, try it. You might find it satisfactory.

Symas does not recommend the SQL backend for high-performance, high-availability use. However, it offers an intriguing option for LDAP access to existing SQL data, where native SQL processes handle actual data maintenance.