Other than this thread:
http://t23307.network-openldap-technical.opennetworks.info/lmdb-growing-the-...
I don't see a discussion of changing the 'maxsize' setting after a LMDB database has been generated.
This thread includes this response about growing the database:
http://www.openldap.org/lists/openldap-technical/201402/msg00302.html
On Windows, Linux, and FreeBSD, there's no problem increasing the mapsize and preserving the existing data.
(I'm making a wild assumption that 'mapsize' is a typo, and 'maxsize' was intended.)
Can 'maxsize' ever be reduced after the fact? If so, is their guidance as to how much it can change (perhaps based on mdb_stat)?
The problem I'm trying to solve:
For my $job, we provide OpenLDAP-backed clustered appliances to customers. The hardware doesn't vary, but the size of individual customers' databases.
- Our strategy for adding members to the cluster involves managing backups (compressed tarballs). Our prior use of the now-ancient bdb backend let these backups be lightweight things to manage for smaller customers, and larger customers would take the hit for having big databases.
- Also, upgrading appliances means importing data from the customers' bdb-based server.
My naive use of the LDMB backend has me assume the worst case, and now everyone is equally punished for having a 'big' (albeit sparse) database.
My hope was to, given awareness of either the data in an LDIF extract, or data about the legacy bdb database itself, we could make a more conservative guess as to a reasonable size for the mdb backend.
Has anyone written up some strategies on these topics, or in the position to provide any recommendation?