[Date Prev][Date Next]
Re: DB corruption master while using syncRepl (ITS#2911)
--On Friday, January 09, 2004 11:13 AM -0500 Jong <jongchoi@OpenLDAP.org>
>> I found that when you are using syncRepl, if you do the following:
>> Start the master and make changes
>> Start the replica (causes a full DB dump)
>> and then make changes while the replica is doing the full DB dump, you
>> can end up with a corrupted BDB database. This happened with just a
>> single replica,
> When was the BDB database corruption observed ?
> - wondering whether the corruption observed during or after the changes.
> And, which are the types of changes made to the provider content ?
>> which concerns me even more about our production environment which has
>> nine replica's.
> The full DB dump occurs at the time when the replica performs the initial
> synchronization of the content. In order to further reduce the
> synchronizatino traffic, the sessionlog can be set up to maintain a
> finite amount of history. If the replica state is
> covered by the sessionlog, the delete mode is used instead of the present
I trolled through my logs yesterday to pull out the sequence of events:
1) Replica contacts master, starts database dump.
2) I connect to master, using ldapadd -f <file> -h <master> to add an entry
to the DB
3) ldapadd finishes, BUT in the logs, the connection is never closed (The
ADD line for that connection is present, nothing else for that connection
4) I do a query against that entry -- It never returns.
5) I do a query against a different preexisting entry -- It never returns
6) I attempt to shut down the master's slapd -- It hangs
7) I kill the master's slapd after a few minutes
8) I db_recover, and then restart the master. I then re-add the entry, and
it is there.
I discussed this with Howard some yesterday, it sounds like a potential
deadlock conflict in BDB occurred.
I will look into setting up the sessionlog... I don't see anything in
slapd.conf about it though, is it an undocumented feature? How would I
specify for my master to keep it?
Principal Software Developer
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html