Dear Folks,
I have a large production 2.4.32 LDAP server slaving many trees. I set it up with memory-mapped files, and want to change it to use shared memory instead, since shared memory BDB seems to work better after watching the other servers that have been upgraded 2.3 => 2.4.32 with shared memory.
To convert this, do I need to slapcat the directories and restore them after the configuration change with slapadd, or is it sufficient to use db_recover in each LDAP database after changing the configuration while slapd is stopped?
--On Monday, August 27, 2012 9:42 AM +1000 Nick Urbanik nick.urbanik@optusnet.com.au wrote:
Dear Folks,
I have a large production 2.4.32 LDAP server slaving many trees. I set it up with memory-mapped files, and want to change it to use shared memory instead, since shared memory BDB seems to work better after watching the other servers that have been upgraded 2.3 => 2.4.32 with shared memory.
To convert this, do I need to slapcat the directories and restore them after the configuration change with slapadd, or is it sufficient to use db_recover in each LDAP database after changing the configuration while slapd is stopped?
All you have to do is modify slapd.conf/cn=config to use a shared memory key. BDB should take care of the rest. There is definitely no need to slapcat/slapadd the DB. A shared memory key changes where BDB stores its cache, not where the database is stored, or how slapd interfaces with BDB.
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
--On Monday, August 27, 2012 9:42 AM +1000 Nick Urbanik nick.urbanik@optusnet.com.au wrote:
Dear Folks,
I have a large production 2.4.32 LDAP server slaving many trees. I set it up with memory-mapped files, and want to change it to use shared memory instead, since shared memory BDB seems to work better after watching the other servers that have been upgraded 2.3 => 2.4.32 with shared memory.
To convert this, do I need to slapcat the directories and restore them after the configuration change with slapadd, or is it sufficient to use db_recover in each LDAP database after changing the configuration while slapd is stopped?
All you have to do is modify slapd.conf/cn=config to use a shared memory key. BDB should take care of the rest. There is definitely no need to slapcat/slapadd the DB. A shared memory key changes where BDB stores its cache, not where the database is stored, or how slapd interfaces with BDB.
If using slapd.conf, you need to manually do a db_recover to make the change take effect.
Dear Quanah and Howard,
Thank you both very much for your help.
On 27/08/12 00:40 -0700, Howard Chu wrote:
Quanah Gibson-Mount wrote:
--On Monday, August 27, 2012 9:42 AM +1000 Nick Urbanik nick.urbanik@optusnet.com.au wrote:
Dear Folks,
I have a large production 2.4.32 LDAP server slaving many trees. I set it up with memory-mapped files, and want to change it to use shared memory instead, since shared memory BDB seems to work better after watching the other servers that have been upgraded 2.3 => 2.4.32 with shared memory.
To convert this, do I need to slapcat the directories and restore them after the configuration change with slapadd, or is it sufficient to use db_recover in each LDAP database after changing the configuration while slapd is stopped?
All you have to do is modify slapd.conf/cn=config to use a shared memory key. BDB should take care of the rest. There is definitely no need to slapcat/slapadd the DB. A shared memory key changes where BDB stores its cache, not where the database is stored, or how slapd interfaces with BDB.
If using slapd.conf, you need to manually do a db_recover to make the change take effect.
Thank you, that is what I did, since I had also changed the cache size in DB_CONFIG, and it all works swimmingly! Thank you.
openldap-technical@openldap.org
-
Howard Chu -
Nick Urbanik -
Quanah Gibson-Mount