Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.144.40) There is currently an issue with back-mdb, where if the database is quite large (10GB+) and the environment is experiencing a heavy write load, that if you start a backup (slapcat or mdb_copy), the database will heavily fragment and grow significantly in size due to the read lock from the slapcat/mdb_copy process. To work around this, slapcat could be given an option to honor the rtxnsize setting in slapd.conf/cn=config. This would allow the read lock to be released periodically and thus reduce the amount of fragmentation that occurs during the backup process. There is not (at this time) a solution proposed for mdb_copy. It should be noted in the man page section for this option that the value of such a backup is of dubious quality, since it is no longer an exact "point in time" representation of the database but rather a bunch of different "point in times" stitched together into a single file.
On 3/29/19 8:58 PM, quanah@openldap.org wrote: > To work around this, slapcat could be given an option to honor the rtxnsize > setting in slapd.conf/cn=config. > [..] > It should be noted in the man page section for this option that the value of > such a backup is of dubious quality, since it is no longer an exact "point in > time" representation of the database but rather a bunch of different "point in > times" stitched together into a single file. Even if slapcat now outputs an exact "point in time" representation of the database this does not say anything about consistency of related LDAP entries anyway. But I wonder how rtxnsize is supposed to interop with LDAP transactions in 2.5.
michael@stroeder.com wrote: > On 3/29/19 8:58 PM, quanah@openldap.org wrote: >> To work around this, slapcat could be given an option to honor the rtxnsize >> setting in slapd.conf/cn=config. >> [..] >> It should be noted in the man page section for this option that the value of >> such a backup is of dubious quality, since it is no longer an exact "point in >> time" representation of the database but rather a bunch of different "point in >> times" stitched together into a single file. > > Even if slapcat now outputs an exact "point in time" representation of > the database this does not say anything about consistency of related > LDAP entries anyway. > > But I wonder how rtxnsize is supposed to interop with > LDAP transactions in 2.5. There is no interaction. LDAP transactions only affect write ops. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/