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

Re: [Bacula-devel] libdbi backend to catalog database

> Kern> When the Bacula drivers become shared objects, Bacula will be
> Kern> capable of working with multiple different database types
> Kern> simultaneously so any new implementation should include that
> Kern> possibility.

I wish you luck in supporting it -- you're going to need it. 

I think the problems of using multiple databases for Bacula internals
and supporting multiple types of database clients are substantially
different, and if you want to support multiple types of databases for
the internals you'll either need to federate the disparate databases
into one view, or pick one for Bacula's internal use and stick with it.
I think there are serious integrity problems that you'll need to solve
if you want to use federated databases for Bacula internals (eg,
holographic table storage, and you'll need to deal with some really hard
failure scenarios that Just Aren't Worth It). 

Reading a simple sequential file on daemon startup and storing the value
in a global variable for use by the various database routines passes the
KISS test in my book, but YMMV. Putting it a current config file is OK
too. In either case, get the value at startup, stuff it somewhere and
pass it behind the scenes.

> So why is this a good thing?  I've never understood the idea to have
> different catalogs either, or what the design goal is.

The original purpose of using the libdbi interface is to remove the
details of the database implementation from the core Bacula code, which
allows support of a much wider range of database engines without
recoding for each one. Libdbi supports postgres, mysql, DB/2, Oracle,
Sybase, kdb, etc, etc via vendor-supplied (and supported) plugins. 

As far as different catalogs go, I've never seen a point in it. Others
may vary. 

> Should I be using different catalogs for each client?

Not unless you have lots of free time to reconcile them in case of a

> Should I be
> using different Pools for each client?

You can, but I wouldn't recommend it unless you have very odd retention
or audit requirements for different clients AND lots of spare time to
debug things. 

This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Bacula-devel mailing list

This mailing list archive is a service of Copilot Consulting.