[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] small dbcheck patch for mysql
On Wednesday 10 September 2008 14:42:12 Bill Moran wrote:
> In response to Marc Schiffbauer <marc@xxxxxxxxxxxxxxx>:
> > * Dan Langille schrieb am 09.09.08 um 22:15 Uhr:
> > > Marc Schiffbauer wrote:
> > > > * Bill Moran schrieb am 09.09.08 um 19:41 Uhr:
> > > >> 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.
> > I was talking about constraints that let the database delete records
> > that would otherwise be "orphaned" records.
> > -> "ON DELETE CASCADE"
> > Would this be to much of a performance impact?
> > Or did I not get the point? :)
> 1) Not supported by all platforms that Bacula supports (unless the project
> has already dropped support for slightly older MySQL versions?)
> 2) Doesn't solve the problem anyway. CASCADE will delete child records
> (file) when parent records (filename) are deleted. The orphan problem
> is the reverse and no SQL engine I'm aware of does that because it
> requires exactly the sort of reference counting overhead that I
> described earlier.
Yes, to support such kinds of SQL, we would need a full time DBA. I have
learned a minimal set of SQL to be able to adequately program Bacula, but I
am not even close to being a DBA so virtually all complicated or non-portable
SQL is out baring some serious input from an experienced DBA (which by the
way we had for the Batch Insert project) -- we do have certain cases where we
have different SQL depending on the engine when it is *required* or when it
gives very important peformance improvements, but use of such coding
drastically increases the chances of bugs and also significantly increases
the maintenance costs.
In a recent version of Bacula (not dbcheck) I did go through the prunning code
and made some very significant improvements in the performance so it is not
that we are not interested in these issues, but just that compared to some of
the new features we are working on, they are really very low in priority --
that said, I am very happy that Yuri stuck with it and resolved a problem and
submitted his code.
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.