Is it possbile to use MMR to my advantage to switch over? For example, take down 1 of the servers, switch the db config from bdb to mdb, and then restart with a blank database (with appropriate structure) and have the MMR take care of backfilling the mdb entries? Then I wouldn't have to export to ldif, convert the db, and reimport while possibly loosing data from the other systems.
On Thu, Nov 1, 2012 at 12:57 PM, Quanah Gibson-Mount quanah@zimbra.comwrote:
--On Thursday, November 01, 2012 12:36 PM -0400 Kyle Smith < alacer.cogitatus@gmail.com> wrote:
Ok, I have been running 2.4.32 for some time with no issues. Yesterday, 2
different servers (both part of a 4-way MMR) produced an "index add failure" and an "index delete failure". I went back over the bdb DB_CONFIG Settings (listed below) and everything looks nominal to me. Would it just make more sense to switch from bdb to mdb instead of troubleshooting these "random" errors too much? I also noticed that the number of "deadlocks" corresponds to the number of errors that were produced. Is there correlation there?
I would suggest back-mdb in OpenLDAP 2.4.33 over back-hdb, yes. It will remove these deadlock issues entirely. When you configure the back-mdb backend in cn=config, be sure to have:
olcDbEnvFlags: writemap olcDbEnvFlags: nometasync
set as well. This makes back-mdb writes significantly faster than writes to back-bdb/hdb. (Some 2x faster in my testing so far).
--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
--On Thursday, November 01, 2012 1:04 PM -0400 Kyle Smith alacer.cogitatus@gmail.com wrote:
Is it possbile to use MMR to my advantage to switch over? For example, take down 1 of the servers, switch the db config from bdb to mdb, and then restart with a blank database (with appropriate structure) and have the MMR take care of backfilling the mdb entries? Then I wouldn't have to export to ldif, convert the db, and reimport while possibly loosing data from the other systems.
Hi Kyle,
I'm not sure what you are trying to avoid here... Slapcat/slapadd are always faster than sync replication. Why would you lose data from the other server while doing this? contextCSNs should be preserved w/ slapcat/slapadd, so the server being converted will just catch up using sync replication as before. You may wish to look at ITS#7427 though. The fix for that is in current RE24.
--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
openldap-technical@openldap.org