| |||||||||||||
Alternatives to SQL DatabasesAlternatives to SQL DatabasesPosted Apr 16, 2009 17:00 UTC (Thu) by intgr (subscriber, #39733)In reply to: Alternatives to SQL Databases by jordanb Parent article: Alternatives to SQL Databases
I think the problem you were having with Sleepycat BDB wans't "corruption" per se. BDB requires an explicit recovery command after an unclean shutdown and many applications using it do not automatically run this.
This annoying feature has probably driven off many of Sleepycat's potential customers.
(Log in to post comments)
Alternatives to SQL Databases Posted Apr 16, 2009 19:43 UTC (Thu) by jordanb (guest, #45668) [Link]
Yeah in this case we tried making the LDAP init script do that, but it seemed to make the problem even worse. We began to suspect that the problem was that there was a version incompatibility between the bdb tools we had and the library being used, which was likely Fedora's fault, but we weren't able to verify that.
But anyway, 'need to explicitly run recovery before attempting to use the database again' is a design failure, imho. The database should be able to recognize that it is not completely consistent and recover itself on startup, and there should always be enough data to reach a consistent state that's not too far from the state when the system crashed.
Alternatives to SQL Databases Posted Apr 23, 2009 14:44 UTC (Thu) by joib (guest, #8541) [Link]
At least on RHEL, you need to use slapd_db_recover rather than dbxx_recover, and similar for the other db_* commands, this will use the correct version of the BDB libraries that openldap was built against.
But yeah, needing manual recovery after a crash is incredibly annoying. Though we have replicated openldap servers that reduce the likelihood of service disruptions due to this.
|
|||||||||||||