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

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


* 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)


-Marc

-- 
BUGS My programs  never  have  bugs.  They  just  develop  random
     features.  If you discover such a feature and you want it to
     be removed: please send an email

-------------------------------------------------------------------------
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
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-devel mailing list
Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilot Consulting.