1SLAPD-BDB(5) File Formats Manual SLAPD-BDB(5)
2
3
4
6 slapd-bdb, slapd-hdb - Berkeley DB backends to slapd
7
9 /etc/openldap/slapd.conf
10
12 The bdb backend to slapd(8) uses the Oracle Berkeley DB (BDB) package
13 to store data. It makes extensive use of indexing and caching to speed
14 data access.
15
16 Note that BDB is deprecated and support will be dropped in future
17 OpenLDAP releases. Installations should use the mdb backend instead.
18
19 hdb is a variant of the bdb backend that uses a hierarchical database
20 layout which supports subtree renames. It is both more space-efficient
21 and more execution-efficient than the bdb backend. It is otherwise
22 identical to the bdb behavior, and all the same configuration options
23 apply.
24
25 It is noted that these options are intended to complement Berkeley DB
26 configuration options set in the environment's DB_CONFIG file. See
27 Berkeley DB documentation for details on DB_CONFIG configuration op‐
28 tions. Where there is overlap, settings in DB_CONFIG take precedence.
29
31 These slapd.conf options apply to the bdb and hdb backend database.
32 That is, they must follow a "database bdb" or "database hdb" line and
33 come before any subsequent "backend" or "database" lines. Other data‐
34 base options are described in the slapd.conf(5) manual page.
35
36 cachesize <integer>
37 Specify the size in entries of the in-memory entry cache main‐
38 tained by the bdb or hdb backend database instance. The default
39 is 1000 entries.
40
41 cachefree <integer>
42 Specify the number of entries to free from the entry cache when
43 the cache reaches the cachesize limit. The default is 1 entry.
44
45 checkpoint <kbyte> <min>
46 Specify the frequency for checkpointing the database transaction
47 log. A checkpoint operation flushes the database buffers to
48 disk and writes a checkpoint record in the log. The checkpoint
49 will occur if either <kbyte> data has been written or <min> min‐
50 utes have passed since the last checkpoint. Both arguments de‐
51 fault to zero, in which case they are ignored. When the <min>
52 argument is non-zero, an internal task will run every <min> min‐
53 utes to perform the checkpoint. See the Berkeley DB reference
54 guide for more details.
55
56 checksum
57 Enable checksum validation of DB pages whenever they are read
58 from disk. This setting can only be configured before any data‐
59 base files are created.
60
61 cryptfile <file>
62 Specify the pathname of a file containing an encryption key to
63 use for encrypting the database. Encryption is performed using
64 Berkeley DB's implementation of AES. Note that encryption can
65 only be configured before any database files are created, and
66 changing the key can only be done after destroying the current
67 database and recreating it. Encryption is not enabled by de‐
68 fault, and some distributions of Berkeley DB do not support en‐
69 cryption.
70
71 cryptkey <key>
72 Specify an encryption key to use for encrypting the database.
73 This option may be used when a separate cryptfile is not de‐
74 sired. Only one of cryptkey or cryptfile may be configured.
75
76 dbconfig <Berkeley-DB-setting>
77 Specify a configuration directive to be placed in the DB_CONFIG
78 file of the database directory. The dbconfig directive is just a
79 convenience to allow all necessary configuration to be set in
80 the slapd.conf file. The options set using this directive will
81 only be written to the DB_CONFIG file if no such file existed at
82 server startup time, otherwise they are completely ignored. This
83 allows one to set initial values without overwriting/destroying
84 a DB_CONFIG file that was already customized through other
85 means. This directive may be specified multiple times, as
86 needed. For example:
87 dbconfig set_cachesize 0 1048576 0
88 dbconfig set_lg_bsize 2097152
89
90 dbnosync
91 Specify that on-disk database contents should not be immediately
92 synchronized with in memory changes. Enabling this option may
93 improve performance at the expense of data security. See the
94 Berkeley DB reference guide for more details.
95
96 dbpagesize <dbfile> <size>
97 Specify the page size to use for a particular database file, in
98 units of 1024 bytes. The default for the id2entry file is 16,
99 the default for all other files depends on the size of the un‐
100 derlying filesystem's block size (typically 4 or 8). The maxi‐
101 mum that BerkeleyDB supports is 64. This setting usually should
102 not need to be changed, but if BerkeleyDB's "db_stat -d" shows a
103 large amount of overflow pages in use in a file, setting a
104 larger size may increase performance at the expense of data in‐
105 tegrity. This setting only takes effect when a database is being
106 newly created. See the Berkeley DB reference guide for more de‐
107 tails.
108
109 directory <directory>
110 Specify the directory where the BDB files containing this data‐
111 base and associated indexes live. A separate directory must be
112 specified for each database. The default is /var/openldap-data.
113
114 dirtyread
115 Allow reads of modified but not yet committed data. Usually
116 transactions are isolated to prevent other operations from ac‐
117 cessing uncommitted data. This option may improve performance,
118 but may also return inconsistent results if the data comes from
119 a transaction that is later aborted. In this case, the modified
120 data is discarded and a subsequent search will return a differ‐
121 ent result.
122
123 dncachesize <integer>
124 Specify the maximum number of DNs in the in-memory DN cache.
125 Ideally this cache should be large enough to contain the DNs of
126 every entry in the database. If set to a smaller value than the
127 cachesize it will be silently increased to equal the cachesize.
128 The default value is 0 which means unlimited, i.e. the DN cache
129 will grow without bound.
130
131 It should be noted that the DN cache is allowed to temporarily
132 grow beyond the configured size. It does this if many entries
133 are locked when it tries to do a purge, because that means
134 they're legitimately in use. Also, the DN cache never purges en‐
135 tries that have cached children, so depending on the shape of
136 the DIT, it could have lots of cached DNs over the defined
137 limit.
138
139 idlcachesize <integer>
140 Specify the size of the in-memory index cache, in index slots.
141 The default is zero. A larger value will speed up frequent
142 searches of indexed entries. An hdb database needs a large idl‐
143 cachesize for good search performance, typically three times the
144 cachesize (entry cache size) or larger.
145
146 index {<attrlist>|default} [pres,eq,approx,sub,<special>]
147 Specify the indexes to maintain for the given attribute (or list
148 of attributes). Some attributes only support a subset of in‐
149 dexes. If only an <attr> is given, the indices specified for
150 default are maintained. Note that setting a default does not
151 imply that all attributes will be indexed. Also, for best per‐
152 formance, an eq index should always be configured for the ob‐
153 jectClass attribute.
154
155 A number of special index parameters may be specified. The in‐
156 dex type sub can be decomposed into subinitial, subany, and sub‐
157 final indices. The special type nolang may be specified to dis‐
158 allow use of this index by language subtypes. The special type
159 nosubtypes may be specified to disallow use of this index by
160 named subtypes. Note: changing index settings in slapd.conf(5)
161 requires rebuilding indices, see slapindex(8); changing index
162 settings dynamically by LDAPModifying "cn=config" automatically
163 causes rebuilding of the indices online in a background task.
164
165 linearindex
166 Tell slapindex to index one attribute at a time. By default, all
167 indexed attributes in an entry are processed at the same time.
168 With this option, each indexed attribute is processed individu‐
169 ally, using multiple passes through the entire database. This
170 option improves slapindex performance when the database size ex‐
171 ceeds the dbcache size. When the dbcache is large enough, this
172 option is not needed and will decrease performance. Also by de‐
173 fault, slapadd performs full indexing and so a separate slapin‐
174 dex run is not needed. With this option, slapadd does no index‐
175 ing and slapindex must be used.
176
177 lockdetect {oldest|youngest|fewest|random|default}
178 Specify which transaction to abort when a deadlock is detected.
179 The default is random.
180
181 mode <integer>
182 Specify the file protection mode that newly created database in‐
183 dex files should have. The default is 0600.
184
185 searchstack <depth>
186 Specify the depth of the stack used for search filter evalua‐
187 tion. Search filters are evaluated on a stack to accommodate
188 nested AND / OR clauses. An individual stack is assigned to each
189 server thread. The depth of the stack determines how complex a
190 filter can be evaluated without requiring any additional memory
191 allocation. Filters that are nested deeper than the search stack
192 depth will cause a separate stack to be allocated for that par‐
193 ticular search operation. These allocations can have a major
194 negative impact on server performance, but specifying too much
195 stack will also consume a great deal of memory. Each search
196 stack uses 512K bytes per level. The default stack depth is 16,
197 thus 8MB per thread is used.
198
199 shm_key <integer>
200 Specify a key for a shared memory BDB environment. By default
201 the BDB environment uses memory mapped files. If a non-zero
202 value is specified, it will be used as the key to identify a
203 shared memory region that will house the environment.
204
206 The bdb and hdb backends honor access control semantics as indicated in
207 slapd.access(5).
208
210 /etc/openldap/slapd.conf
211 default slapd configuration file
212
213 DB_CONFIG
214 Berkeley DB configuration file
215
217 slapd.conf(5), slapd-config(5), slapd-mdb(5), slapd(8), slapadd(8),
218 slapcat(8), slapindex(8), Berkeley DB documentation.
219
221 OpenLDAP Software is developed and maintained by The OpenLDAP Project
222 <http://www.openldap.org/>. OpenLDAP Software is derived from the Uni‐
223 versity of Michigan LDAP 3.3 Release. Originally begun by Kurt
224 Zeilenga. Caching mechanisms originally designed by Jong-Hyuk Choi.
225 Completion and subsequent work, as well as back-hdb, by Howard Chu.
226
227
228
229OpenLDAP 2021/06/03 SLAPD-BDB(5)