Comment 38 for bug 16317

Revision history for this message
Debian Bug Importer (debzilla) wrote :

Message-ID: <email address hidden>
Date: Sat, 21 May 2005 21:22:30 -0500
From: Micah Anderson <email address hidden>
To: <email address hidden>
Cc: <email address hidden>
Subject: DB_TXN_NOSYN

--vkogqOf2sHV7VnPd
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Setting DB_TXN_NOSYN in DB_CONFIG when loading your database is a good
thing to do to speed up performance, this is because writes will not
be flushed or logs written on transaction commit. If you *leave this
setting set* and your application fails, or you loose power on your
system, it is possible some number of the most recently committed
transactions may be undone during recovery. The number of transactions
at risk is governed by how many log updates can fit into the log
buffer, how often the operating system flushes dirty buffers to disk,
and how often the log is checkpointed. Even worse, if there is
database or transaction log file loss or corruption (for example, if a
disk drive fails), then catastrophic recovery (read: from backups) is
necessary, and Berkeley DB recovery will only be able to restore the
system to the state of the last archived log file. In this case,
information may also have been lost.

After your data has been loaded, DB_TXN_NOSYN should *be removed* from
DB_CONFIG and slapd restarted. Although many parameters in DB_CONFIG
(such as cachesize) can only be set once as they apply to the creation
of the database environment and to change them you need to destroy and
recreate it, the DB_TXN_NOSYNC flag can be changed between runs.

Setting DB_TXN_NOSYNC should *only* be done to increase performance at
the cost of sacrificing transactional durability, except in replicated
environments (see http://www.sleepycat.com/docs/ref/rep/trans.html).

What many people do (if you search the openldap mailing list you will
confirm this), is to set the following in the DB_CONFIG:

# Just use these settings when doing slapadd, comment them out
# and reload slapd afterwards, or risk data loss
#set_flags DB_TXN_NOSYNC
#set_flags DB_TXN_NOT_DURABLE

this way they are commented out, and there is a warning. When you go
and do your slapadd you uncomment them, fire things up and then
slapadd. When you are done you comment them out and reload slapd. You
*can* leave these enabled, but you are risking data loss.

See for reference:=20
http://www.openldap.org/faq/index.cgi?_highlightWords=3Ddb_txn_nosync&file=
=3D1072
http://www.openldap.org/faq/index.cgi?_highlightWords=3Ddb_txn_nosync&file=
=3D893

It is also highly recommended that you tune your BDB environment
according to your needs or you will experience slowdown, see the
following:
http://www.stanford.edu/services/directory/openldap/configuration/bdb-confi=
g-42.html
http://www.openldap.org/faq/data/cache/1075.html

Micah

--vkogqOf2sHV7VnPd
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCj+zm9n4qXRzy1ioRAl8kAJ9M6UqE1n+oI0esMwX+1Mi95PHlNgCfTdp0
ghWQb6Ki4NBuTsQCCfzwT64=
=97if
-----END PGP SIGNATURE-----

--vkogqOf2sHV7VnPd--