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?
It's the amount of disk space used (DB+freespace table, etc)
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?
If you change the maxsize while slapd is down, it won't get applied until you start slapd. If you're using cn=config, and change it while slapd's running, the change is immediate. My deployments used cn=config, and the script would just modify the maxsize while slapd was running.
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?
I'll discuss with Howard, and see. I hate seeing more options added to slapd, but it may be the only option (no pun intended!) for this scenario. ;) The cloud was fairly nascent when this was all designed, so this case wasn't really a consideration at that point in time. If you were to pass in the server ID, I think you could get rid of the multi-valued serverID bit entirely, since every server would know who it was already.
--Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>