On Wed, Jan 24, 2018 at 09:27:20AM -0800, Quanah Gibson-Mount wrote:
Please ellaborate on what is risky (or load inducing) about changing the maxsize.
It is entirely my assumption - wrong it would appear, which is good news! I was thinking of this as something like grow/shrink ops on filesystems.
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 DB
In 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)
Is 'size of the DB' the current length of the DB file, or the amount of disk space actually used by it?
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.
Just to be clear on this, is it OK to change maxsize in the config file while slapd is down or does this only work with LDAP-based config changes?
The other problem is definitely interesting, and I'm not clear on a good solution for it.
How about adding a flag to slapd to specify the server ID so that it can go the other way through the config, convert ID to FQDN, and drop that FQDN from the set of replication sources?
Andrew