Just one more bit of info:
After rsync copies the 80 GB file, "du -sh" will report the NEW file as an 80GB file rather than the original 3.3MB file.
The post between Quanah and OpenLDAP also appears to confirm the file size / reporting issue.
However, we're still lacking a solution to the problem. Is this something that can be handled using OpenLDAP rather than Zimbra commands?
Looking at slapd-mdb .
Didn`t find a way to "roll" this file......:confused:
Specify the maximum size of the database in bytes. A memory map of this size is allocated at startup time and the database will not be allowed to grow beyond this size. The default is 10485760 bytes. This setting may be changed upward if the configured limit needs to be increased.
Note: It is important to set this to as large a value as possi- ble, (relative to anticipated growth of the actual data over time) since growing the size later may not be practical when the system is under heavy load.
Yep I concur, du -c -h data.mdb on copied file is 81GB not 7MB.
Just thought I'd try an intermediate solution of:
Restarted the services...did NOT change the file size--still 80GB. I was aiming for 64MB.Code:
zmlocalconfig -e ldap_db_maxsize=67108864
zmlocalconfig -e ldap_accesslog_maxsize=67108864
It was a long-shot, but worth the try anyway...
I've filled a RFE Bug 78781 – LDAP data.mdb file allocate 80 GB
I suggest running du -c -h on the file. It is not 80GB. 80GB is purely the default maximum amount it can use up to.
Also, note that the supported method of backing up ldap has been, and always will be via LDIF. That is why zmslapcat exports the database to LDIF. If you are using cp or rsync to back up the LDAP DB, you are applying an incorrect backup methodology.
I would suggest you fix your backup strategy to what OpenLDAP supports. Which is to export the database, via slapcat, to an LDIF file.
The rsync approach has been part of the recommended process for Zimbra FOSS for a very long time. As someone else has mentioned that this 80GB on copy was not happening in v8 when the DB changed can you suggest why it is happening this time in v8.0.1?With respect if we follow the previous recommendations from Zimbra devs/staff for FOSS and we end up at this current position I would suggest that the guidance offered to us has been incorrect not that our strategy per se is wrong. The tone of your comments suggests you think we are incapable or stupid, which is unfair and unjustified. This current change is only apparent now and it certainly hasn't been the case before.Can you kindly explain why it has been changed to be structured like this so we can understand and perhaps why it has happened without any warning or prior advice.