|
slapd−bdb, slapd−hdb — Berkeley DB backends to slapd
ETCDIR/slapd.conf
The bdb
backend
to slapd(8) uses the Oracle
Berkeley DB (BDB) package to store data. It makes extensive
use of indexing and caching to speed data access.
hdb
is the
recommended primary database backend. It is a variant of the
bdb
backend that
uses a hierarchical database layout which supports subtree
renames. It is both more space-efficient and more
execution-efficient than the bdb
backend. It is otherwise
identical to the bdb
behavior, and all the
same configuration options apply.
It is noted that these options are intended to complement
Berkeley DB configuration options set in the environment's
DB_CONFIG
file. See Berkeley DB
documentation for details on DB_CONFIG
configuration options. Where
there is overlap, settings in DB_CONFIG
take precedence.
These slapd.conf
options apply to the bdb
and hdb
backend database. That
is, they must follow a "database bdb" or "database hdb" line
and come before any subsequent "backend" or "database" lines.
Other database options are described in the slapd.conf(5) manual
page.
cachesize
<integer>
Specify the size in entries of the in-memory entry
cache maintained by the bdb
or hdb
backend database
instance. The default is 1000 entries.
cachefree
<integer>
Specify the number of entries to free from the entry
cache when the cache reaches the cachesize
limit. The
default is 1 entry.
checkpoint
<kbyte>
<min>Specify the frequency for checkpointing the database
transaction log. A checkpoint operation flushes the
database buffers to disk and writes a checkpoint record
in the log. The checkpoint will occur if either
<kbyte>
data has been written or <min>
minutes
have passed since the last checkpoint. Both arguments
default to zero, in which case they are ignored. When
the <min>
argument is
non-zero, an internal task will run every <min>
minutes to
perform the checkpoint. See the Berkeley DB reference
guide for more details.
checksum
Enable checksum validation of DB pages whenever they are read from disk. This setting can only be configured before any database files are created.
cryptfile
<file>
Specify the pathname of a file containing an encryption key to use for encrypting the database. Encryption is performed using Berkeley DB's implementation of AES. Note that encryption can only be configured before any database files are created, and changing the key can only be done after destroying the current database and recreating it. Encryption is not enabled by default, and some distributions of Berkeley DB do not support encryption.
cryptkey
<key>
Specify an encryption key to use for encrypting the
database. This option may be used when a separate
cryptfile
is
not desired. Only one of cryptkey
or cryptfile
may be
configured.
dbconfig
<Berkeley-DB-setting>
Specify a configuration directive to be placed in
the DB_CONFIG
file of the
database directory. The dbconfig
directive is
just a convenience to allow all necessary configuration
to be set in the slapd.conf
file. The
options set using this directive will only be written
to the DB_CONFIG
file if
no such file existed at server startup time, otherwise
they are completely ignored. This allows one to set
initial values without overwriting/destroying a
DB_CONFIG
file that was
already customized through other means. This directive
may be specified multiple times, as needed. For
example:
dbconfig set_cachesize 0 1048576 0 dbconfig set_lg_bsize 2097152
dbnosync
Specify that on-disk database contents should not be immediately synchronized with in memory changes. Enabling this option may improve performance at the expense of data security. See the Berkeley DB reference guide for more details.
Specify the page size to use for a particular
database file, in units of 1024 bytes. The default for
the id2entry
file is 16, the default for all other files depends on
the size of the underlying filesystem's block size
(typically 4 or 8). The maximum that BerkeleyDB
supports is 64. This setting usually should not need to
be changed, but if BerkeleyDB's "db_stat −d"
shows a large amount of overflow pages in use in a
file, setting a larger size may increase performance at
the expense of data integrity. This setting only takes
effect when a database is being newly created. See the
Berkeley DB reference guide for more details.
directory
<directory>
Specify the directory where the BDB files containing
this database and associated indexes live. A separate
directory must be specified for each database. The
default is LOCALSTATEDIR/openldap−data
.
dirtyread
Allow reads of modified but not yet committed data. Usually transactions are isolated to prevent other operations from accessing uncommitted data. This option may improve performance, but may also return inconsistent results if the data comes from a transaction that is later aborted. In this case, the modified data is discarded and a subsequent search will return a different result.
dncachesize
<integer>
Specify the maximum number of DNs in the in-memory
DN cache. Ideally this cache should be large enough to
contain the DNs of every entry in the database. If set
to a smaller value than the cachesize
it will be
silently increased to equal the cachesize
. The default
value is 0 which means unlimited, i.e. the DN cache
will grow without bound.
It should be noted that the DN cache is allowed to temporarily grow beyond the configured size. It does this if many entries are locked when it tries to do a purge, because that means they're legitimately in use. Also, the DN cache never purges entries that have cached children, so depending on the shape of the DIT, it could have lots of cached DNs over the defined limit.
idlcachesize
<integer>
Specify the size of the in-memory index cache, in
index slots. The default is zero. A larger value will
speed up frequent searches of indexed entries. An
hdb
database
needs a large idlcachesize
for good
search performance, typically three times the
cachesize
(entry cache size) or larger.
<attrlist>
|default
}
[pres
,eq
,approx
,sub
,<special>
]Specify the indexes to maintain for the given
attribute (or list of attributes). Some attributes only
support a subset of indexes. If only an <attr>
is given,
the indices specified for default
are maintained.
Note that setting a default does not imply that all
attributes will be indexed. Also, for best performance,
an eq
index
should always be configured for the objectClass
attribute.
A number of special index parameters may be
specified. The index type sub
can be decomposed
into subinitial
, subany
, and subfinal
indices. The
special type nolang
may be specified
to disallow use of this index by language subtypes. The
special type nosubtypes
may be
specified to disallow use of this index by named
subtypes. Note: changing index
settings in
slapd.conf(5)
requires rebuilding indices, see slapindex(8);
changing index
settings
dynamically by LDAPModifying "cn=config" automatically
causes rebuilding of the indices online in a background
task.
linearindex
Tell slapindex
to index one
attribute at a time. By default, all indexed attributes
in an entry are processed at the same time. With this
option, each indexed attribute is processed
individually, using multiple passes through the entire
database. This option improves slapindex
performance
when the database size exceeds the dbcache
size. When the
dbcache
is
large enough, this option is not needed and will
decrease performance. Also by default, slapadd
performs full
indexing and so a separate slapindex
run is not
needed. With this option, slapadd
does no
indexing and slapindex
must be
used.
lockdetect
{
oldest|
youngest|
fewest|
random|
default}
Specify which transaction to abort when a deadlock
is detected. The default is random
.
mode
<integer>
Specify the file protection mode that newly created database index files should have. The default is 0600.
searchstack
<depth>
Specify the depth of the stack used for search filter evaluation. Search filters are evaluated on a stack to accommodate nested AND / OR clauses. An individual stack is assigned to each server thread. The depth of the stack determines how complex a filter can be evaluated without requiring any additional memory allocation. Filters that are nested deeper than the search stack depth will cause a separate stack to be allocated for that particular search operation. These allocations can have a major negative impact on server performance, but specifying too much stack will also consume a great deal of memory. Each search stack uses 512K bytes per level. The default stack depth is 16, thus 8MB per thread is used.
shm_key
<integer>
Specify a key for a shared memory BDB environment. By default the BDB environment uses memory mapped files. If a non-zero value is specified, it will be used as the key to identify a shared memory region that will house the environment.
The bdb
and
hdb
backends honor
access control semantics as indicated in slapd.access(5).
slapd.conf(5), slapd-config(5), slapd(8), slapadd(8), slapcat(8), slapindex(8), Berkeley DB documentation.
OpenLDAP Software is developed and maintained by The OpenLDAP Project <http://www.openldap.org/>. OpenLDAP Software is derived from University of Michigan LDAP 3.3 Release. Originally begun by Kurt Zeilenga. Caching mechanisms originally designed by Jong-Hyuk Choi. Completion and subsequent work, as well as back-hdb, by Howard Chu.