---- START access-control.html ----
---- END access-control.html ----
---- START appendix-changes.html ----
---- END appendix-changes.html ----
---- START appendix-common-errors.html ----
---- END appendix-common-errors.html ----
---- START appendix-configs.html ----
---- END appendix-configs.html ----
---- START appendix-contrib.html ----
---- END appendix-contrib.html ----
---- START appendix-deployments.html ----
---- END appendix-deployments.html ----
---- START appendix-ldap-result-codes.html ----
---- END appendix-ldap-result-codes.html ----
---- START appendix-recommended-versions.html ----
---- END appendix-recommended-versions.html ----
---- START appendix-upgrading.html ----
---- END appendix-upgrading.html ----
---- START autoconf.html ----
---- END autoconf.html ----
---- START backends.html ----
82c82
< directory "./ldif"
---
> directory ./ldif
126c126
<
---
>
127a128,147
> The mdb backend to slapd(8) is the upcoming primary backend for a normal slapd database. It uses OpenLDAP's own Memory-Mapped Database (MDB) library to store data and is intended to replace the Berkeley DB backends.
> It supports indexing like the BDB backends, but it uses no caching and requires no tuning to deliver maximum search performance. Like hdb, it is also fully hierarchical and supports subtree renames in constant time.
>
> Unlike the BDB backends, the MDB backend can be instantiated with very few configuration lines:
>
> include ./schema/core.schema
>
> database mdb
> directory ./mdb
> suffix "dc=suretecsystems,dc=com"
> rootdn "cn=mdb,dc=suretecsystems,dc=com"
> rootpw mdb
> maxsize 1073741824
>
> In addition to the usual parameters that a minimal configuration requires, the MDB backend requires a maximum size to be set. This should be the largest that the database is ever anticipated to grow (in bytes). The filesystem must also provide enough free space to accommodate this size.
>
> slapd-mdb(5)
>
>
>
131c151
<
---
>
133c153
<
---
>
136,137c156,157
<
<
---
>
>
141c161
<
---
>
188c208
<
---
>
191,192c211,212
<
<
---
>
>
201c221
<
---
>
227c247
<
---
>
230,231c250,251
<
<
---
>
>
234c254
<
---
>
267c287
<
---
>
270,271c290,291
<
<
---
>
>
274c294
<
---
>
276c296
<
---
>
279,280c299,300
<
<
---
>
>
283c303
<
---
>
285c305
<
---
>
288,289c308,309
<
<
---
>
>
296c316
<
---
>
359c379
<
---
>
---- END backends.html ----
---- START config.html ----
---- END config.html ----
---- START copyright.html ----
---- END copyright.html ----
---- START dbtools.html ----
---- END dbtools.html ----
---- START glossary.html ----
621a622,629
> MDB
>
>
> Memory-Mapped Database
> |
>
>
>
---- END glossary.html ----
---- START index.html ----
26c26
< 31 July 2012
---
> 3 March 2013
246c246
< 11.4. Metadirectory
---
> 11.4. MDB
249c249
< 11.4.2. back-meta Configuration
---
> 11.4.2. back-mdb Configuration
253c253
< 11.5. Monitor
---
> 11.5. Metadirectory
256c256
< 11.5.2. back-monitor Configuration
---
> 11.5.2. back-meta Configuration
260c260
< 11.6. Null
---
> 11.6. Monitor
263c263
< 11.6.2. back-null Configuration
---
> 11.6.2. back-monitor Configuration
267c267
< 11.7. Passwd
---- END index.html ----
---- START install.html ----
---- END install.html ----
---- START intro.html ----
---- END intro.html ----
---- START license.html ----
---- END license.html ----
---- START limits.html ----
---- END limits.html ----
---- START maintenance.html ----
---- END maintenance.html ----
---- START monitoringslapd.html ----
---- END monitoringslapd.html ----
---- START overlays.html ----
---- END overlays.html ----
---- START preface.html ----
---- END preface.html ----
---- START quickstart.html ----
---- END quickstart.html ----
---- START referrals.html ----
---- END referrals.html ----
---- START replication.html ----
112,113c112
< - If backing up the Berkeley database itself and periodically backing up the transaction log files, then the same member of the mirror pair needs to be used to collect logfiles until the next database backup is taken
< - Delta-Syncrepl is not yet supported
---
> - If backing up the Berkeley database itself and periodically backing up the transaction log files, then the same member of the mirror pair needs to be used to collect logfiles until the next database backup is taken
407,409d405
<
< Note: Delta-syncrepl is not yet supported with MirrorMode.
<
---- END replication.html ----
---- START runningslapd.html ----
---- END runningslapd.html ----
---- START sasl.html ----
---- END sasl.html ----
---- START schema.html ----
---- END schema.html ----
---- START security.html ----
---- END security.html ----
---- START slapdconf2.html ----
39c39
< Note: You will need to continue to use the older slapd.conf(5) configuration system if your OpenLDAP installation requires the use of one or more backends or overlays that have not been updated to use the slapd-config(5) system. As of OpenLDAP 2.4.25, the only official backends that have not yet been updated to use slapd-config(5) are slapd-meta(5) and slapd-sql(5). There may be additional contributed or experimental overlays that also have not been updated.
---
> Note: You will need to continue to use the older slapd.conf(5) configuration system if your OpenLDAP installation requires the use of one or more backends or overlays that have not been updated to use the slapd-config(5) system. As of OpenLDAP 2.4.33, all of the official backends have been updated. There may be additional contributed or experimental overlays that also have not been updated.
---- END slapdconf2.html ----
---- START slapdconfig.html ----
---- END slapdconfig.html ----
---- START tls.html ----
---- END tls.html ----
---- START troubleshooting.html ----
---- END troubleshooting.html ----
---- START tuning.html ----
33c33
< See Caching
---
> See Caching for BDB cache tuning hints. Note that MDB uses no cache of its own and has no tuning options, so the Caching section can be ignored when using MDB.
35c35,36
< Use fast subsystems. Put each database and logs on separate disks configurable via DB_CONFIG:
---
> Use fast filesystems, and conduct your own testing to see which filesystem types perform best with your workload. (On our own Linux testing, EXT2 and JFS tend to provide better write performance than everything else, including newer filesystems like EXT4, BTRFS, etc.)
> Use fast subsystems. Put each database and logs on separate disks (for BDB this is configurable via DB_CONFIG):
145,146c146,148
<
< slapd(8) can process requests via a configurable number of thread, which in turn affects the in/out rate of connections.
---
>
>
> slapd(8) can process requests via a configurable number of threads, which in turn affects the in/out rate of connections.
---- END tuning.html ----
|