[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] small dbcheck patch for mysql

Marc Schiffbauer wrote:
> * Bill Moran schrieb am 09.09.08 um 19:41 Uhr:
>> In response to Dan Langille <dan@xxxxxxxxxxxx>:
>>> Bill Moran wrote:
>>>> So, my question would be, is dbcheck's performance important enough to
>>>> do that with?  As a utility program that doesn't really get run that
>>>> often, it's quite likely a misdirection of resources.  Granted, don't
>>>> turn down the patch ... if it helps MySQL without hurting anything else,
>>>> go for it.
>>> Point: If everything Bacula does is within a transaction, why is dbcheck 
>>> required?
>> Correct me if I'm wrong, but I don't believe that the orphaned filename/
>> path issue is the result of crashes or other non-transactional issues.  I
>> know for a fact that our primary Bacula server has run for many months
>> without failure and it has still accumulated many orphaned paths and
>> filenames.
>> My understanding of what happens is this:
>> 1) Job runs and creates a filename entry for a filename not used before
>>    (let's say something really unique, such as would be created by
>>    mktemp)
>> 2) Time goes by and that file is deleted, never to be seen again.
>>    Eventually, Bacula gets to a point where all the jobs that backed
>>    up that filename have been pruned, thus there are no longer any
>>    file entries referencing that row.
>> 3) Now we have an orphaned filname row in that table.
>> The same thing can happen with path.
> In a clean database design the database would care for this itself.
> Why not let the database delete any rows that are not referenced
> anymore?
>> The canonical way to solve this would be to keep a reference counter in
>> the filename/path tables that keeps track of how many file entries
>> reference that row.  When it's hits 0, it can be deleted.  But this
>> creates other issues:
>> 1) What is the overhead of maintaining the reference counter?
>> 2) In the case of a crash, we _must_ fix all reference counters immediately,
>>    otherwise records could be deleted that still need to be used.
>> Referential integrity doesn't even gain us much here, as that only
>> guarantees that records can't be created that don't have proper
>> references, it doesn't automatically clean up after deletes.
> AFAIK it does work if the database is properly created, not?
> (with foreign keys)

What are you talking about?  :)  Please elaborate.

Dan Langille

BSDCan - The Technical BSD Conference : http://www.bsdcan.org/
PGCon  - The PostgreSQL Conference:     http://www.pgcon.org/

This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Bacula-devel mailing list

This mailing list archive is a service of Copilot Consulting.