[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
> 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)
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
Bacula-devel mailing list
This mailing list archive is a service of Copilot Consulting.