[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
>> 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
>> 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
>> 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
>> 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.
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.