You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Emmanuel Lécharny <el...@gmail.com> on 2016/01/25 12:21:33 UTC
Database corruption, some interesting finding !
Hi guys,
while working on the repair() function, iI found something very
interesting.
When we update a partition, at the end, we call the sync() method which
writes down on disk all the updates which are pending in memory. This
sync() method itself sync all the indexes :
/**
* This method is called when the synch thread is waking up, to write
* the modified data.
*
* @throws Exception on failures to sync database files to disk
*/
public synchronized void sync() throws Exception
{
if ( !initialized )
{
return;
}
// Sync all system indices
for ( Index<?, String> idx : systemIndices.values() )
{
idx.sync();
}
// Sync all user defined userIndices
for ( Index<?, String> idx : userIndices.values() )
{
idx.sync();
}
// Sync the master table
( ( JdbmMasterTable ) master ).sync();
}
Sadly, the rdnIndex is *never* flushed explicitely - so it's done only
periodically (every 2000 updates, the default):
/**
* Commit the modification on disk
*
* @param recordManager The recordManager used for the commit
*/
private void commit( RecordManager recordManager ) throws IOException
{
if ( commitNumber.incrementAndGet() % 2000 == 0 )
{
sync();
}
}
This is *BAD*. That means we may have some pending modifications of this
RDN index that are not written on disk when we stop the server or when
we have a crash :/
Adding a rdnIdx.sync() might be just enough to eliminate the corruptions
we see...
In any case, we still need the repair tool.
Re: Database corruption, some interesting finding !
Posted by Kiran Ayyagari <ka...@apache.org>.
On Mon, Jan 25, 2016 at 5:09 PM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Le 25/01/16 12:33, Kiran Ayyagari a écrit :
> > On Mon, Jan 25, 2016 at 4:51 PM, Emmanuel Lécharny <el...@gmail.com>
> > wrote:
> >
> >> Hi guys,
> >>
> >> while working on the repair() function, iI found something very
> >> interesting.
> >>
> >> When we update a partition, at the end, we call the sync() method which
> >> writes down on disk all the updates which are pending in memory. This
> >> sync() method itself sync all the indexes :
> >>
> >> /**
> >> * This method is called when the synch thread is waking up, to
> write
> >> * the modified data.
> >> *
> >> * @throws Exception on failures to sync database files to disk
> >> */
> >> public synchronized void sync() throws Exception
> >> {
> >> if ( !initialized )
> >> {
> >> return;
> >> }
> >>
> >> // Sync all system indices
> >> for ( Index<?, String> idx : systemIndices.values() )
> >> {
> >> idx.sync();
> >> }
> >>
> > the above call should cover this case cause JdbmRdnIndex extends
> JdbmIndex
>
> Damn it, I'm wrong... The rdnIndex is covered. Here is the list of
> system indexes :
>
> {
> 2.5.4.0=Index<objectClass>,
> 1.3.6.1.4.1.18060.0.4.1.2.3=Index<apachePresence>,
> 1.3.6.1.4.1.18060.0.4.1.2.5=Index<apacheOneAlias>,
> 1.3.6.1.4.1.18060.0.4.1.2.6=Index<apacheSubAlias>,
> 1.3.6.1.4.1.18060.0.4.1.2.7=Index<1.3.6.1.4.1.18060.0.4.1.2.7>, //
> The Alias index
> 1.3.6.1.4.1.4203.666.1.7=Index<entryCSN>,
> 1.3.6.1.4.1.18060.0.4.1.2.50=Index<1.3.6.1.4.1.18060.0.4.1.2.50>, //
> The RDN index <--------
> 2.5.18.5=Index<administrativeRole>
> }
>
> Sorry...
>
nah, you uncovered a far more serious issue with the repair tool regarding
RDN index child counts
Re: Database corruption, some interesting finding !
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 25/01/16 12:33, Kiran Ayyagari a écrit :
> On Mon, Jan 25, 2016 at 4:51 PM, Emmanuel Lécharny <el...@gmail.com>
> wrote:
>
>> Hi guys,
>>
>> while working on the repair() function, iI found something very
>> interesting.
>>
>> When we update a partition, at the end, we call the sync() method which
>> writes down on disk all the updates which are pending in memory. This
>> sync() method itself sync all the indexes :
>>
>> /**
>> * This method is called when the synch thread is waking up, to write
>> * the modified data.
>> *
>> * @throws Exception on failures to sync database files to disk
>> */
>> public synchronized void sync() throws Exception
>> {
>> if ( !initialized )
>> {
>> return;
>> }
>>
>> // Sync all system indices
>> for ( Index<?, String> idx : systemIndices.values() )
>> {
>> idx.sync();
>> }
>>
> the above call should cover this case cause JdbmRdnIndex extends JdbmIndex
Damn it, I'm wrong... The rdnIndex is covered. Here is the list of
system indexes :
{
2.5.4.0=Index<objectClass>,
1.3.6.1.4.1.18060.0.4.1.2.3=Index<apachePresence>,
1.3.6.1.4.1.18060.0.4.1.2.5=Index<apacheOneAlias>,
1.3.6.1.4.1.18060.0.4.1.2.6=Index<apacheSubAlias>,
1.3.6.1.4.1.18060.0.4.1.2.7=Index<1.3.6.1.4.1.18060.0.4.1.2.7>, //
The Alias index
1.3.6.1.4.1.4203.666.1.7=Index<entryCSN>,
1.3.6.1.4.1.18060.0.4.1.2.50=Index<1.3.6.1.4.1.18060.0.4.1.2.50>, //
The RDN index <--------
2.5.18.5=Index<administrativeRole>
}
Sorry...
Re: Database corruption, some interesting finding !
Posted by Kiran Ayyagari <ka...@apache.org>.
On Mon, Jan 25, 2016 at 4:51 PM, Emmanuel Lécharny <el...@gmail.com>
wrote:
> Hi guys,
>
> while working on the repair() function, iI found something very
> interesting.
>
> When we update a partition, at the end, we call the sync() method which
> writes down on disk all the updates which are pending in memory. This
> sync() method itself sync all the indexes :
>
> /**
> * This method is called when the synch thread is waking up, to write
> * the modified data.
> *
> * @throws Exception on failures to sync database files to disk
> */
> public synchronized void sync() throws Exception
> {
> if ( !initialized )
> {
> return;
> }
>
> // Sync all system indices
> for ( Index<?, String> idx : systemIndices.values() )
> {
> idx.sync();
> }
>
the above call should cover this case cause JdbmRdnIndex extends JdbmIndex
>
> // Sync all user defined userIndices
> for ( Index<?, String> idx : userIndices.values() )
> {
> idx.sync();
> }
>
> // Sync the master table
> ( ( JdbmMasterTable ) master ).sync();
> }
>
> Sadly, the rdnIndex is *never* flushed explicitely - so it's done only
> periodically (every 2000 updates, the default):
>
> /**
> * Commit the modification on disk
> *
> * @param recordManager The recordManager used for the commit
> */
> private void commit( RecordManager recordManager ) throws IOException
> {
> if ( commitNumber.incrementAndGet() % 2000 == 0 )
> {
> sync();
> }
> }
>
>
> This is *BAD*. That means we may have some pending modifications of this
> RDN index that are not written on disk when we stop the server or when
> we have a crash :/
>
> Adding a rdnIdx.sync() might be just enough to eliminate the corruptions
> we see...
>
>
> In any case, we still need the repair tool.
>
>