[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: best practices WRT resizing a MDB backend?

Brian Reichert wrote:
Other than this thread:


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:


   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.)

maxsize is the back-mdb keyword. mapsize is the LMDB API property. They both refer to the same thing. We used the word "maxsize" for back-mdb to impress upon sysadmins that this really is a long-term maximum, and not a setting that should be tuned on an ongoing basis.

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)?

Read the LMDB documentation.

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)

"Punished"? There is no penalty for configuring a large maxsize, no matter how small the actual data.

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

There's no reason to bother doing this.

Has anyone written up some strategies on these topics, or in the
position to provide any recommendation?

  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/