On Wed, Jan 24, 2018 at 06:37:43AM -0800, Quanah Gibson-Mount wrote:You can change the MDB maxsize at any time, including while slapd is running. So that scenario at least doesn't compute. ;)I would still rather do such risky / load-inducing changes on one replica at a time. Anyway, running with fully-replicated config makes it even more important to have a good solution to the problem I described.
Please ellaborate on what is risky (or load inducing) about changing the maxsize. I've had a script for years that has automatically adjusted the maxsize as necessary based on the size of the DB vs maxsize, etc, via cn=config. This script has been deployed on servers throughout the world via my former job @ Zimbra. Changing the maxsize has never been a problem.
You have 3 basic scenarios: #1: You decrease the maxsize to < size of the DB #2: You set the maxsize = to the size of the DB #3: You increase the maxsize > size of the DBIn scenario #1, lmdb refuses to set the maxsize to something less than the size of the DB. It will make it equal to the size of the DB (Leading to scenario #2)
In scenario #2, the server will not accept any new growth (write ops will be rejected). Monitoring should alert you to that, but the system will recover once you adjust the maxsize to something useful.
In scenario #3, the maxsize is increased.I've not seen any load related issues for such an operation, so it's not clear to me what you mean by that, either.
The other problem is definitely interesting, and I'm not clear on a good solution for it.
--Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>