[Dbconfig-common-devel] Questions about upgrading

[Ross Boylan]

On Sat, Jul 08, 2006 at 05:54:19PM -0400, sean finney wrote:
> 
> > Configure database for bacula-director-pgsql with dbconfig-common? no
> 
> so you said no because you already had an existing bacula db setup.
> i'm going from memory here, but i think that this also disables any
> attempt at automatic upgrade support.  
> 
> i *think* you can safely say yes here if you're upgrading, without it
> trying to install a new database on top of your own.  

Would dpkg-reconfigure do any good, or will the fact that it wouldn't
change package versions imply none of the dbconfig upgrade code gets
run?

I've also re-remembered that my situation actually involves both the
multiple database version/multiple instances problem.  The bacula
database in in postgres 7.4 database; I am also running postgres 8.1.
Since 7.4 was there first it just  so happens the psql connects to it
on the default port.  It also seems that psql, which gets a wrapper,
pulls in the right version of psql for that database.

If dbconfig has code to detect an existing database, it may be that
one or more of those issues (multiple DB's and versions, multiple
ports, multiple client versions) caused the search to fail.  It should
be using the database contact info from bacula's configuration; I'm
not sure if it does.      

> 
> > bacula-director-pgsql clearly has upgrade scripts, specifically
> > /usr/share/dbconfig-common/data/bacula-director-pgsql/upgrade/pgsql/1.38.0.
> > 
> > Is there anything I can do that will invoke them?
> 
> yes... the contents of that file should be basic sql commands.  you can
> probably do something like
> 
> psql -U bacula bacula < /usr/share/dbconfig-common/data/bacula-director-pgsql/upgrade/pgsql/1.38.0.
> 

That's really useful to know.  There is so much stuff going on in
dbconfig that I wasn't sure it was that simple.

> assuming user/database named bacula.  of course, you should make a
> backup of the data first just in case :)

Yep: I need to backup my backup!  Actually, my regular backups should
have a fairly recent one, at least.

> 
> > Though I see the upgrade scripts, I do not see hooks for upgrading in
> > the package postinst scripts (or other scripts I looked at).  The TODO
> 
> the upgrade is handled by dbconfig-common's hooks, and is indirectly
> reached by calling dbc_go in the postinst script.  if you want to
> see what's really happening, the file with all the action is
> /usr/share/dbconfig-common/dpkg/postinst, though that's only
> if you're curious.

Thanks for the tip.

...

> > As far as I can tell, dbconfig couples the upgrade of the packages
> > database with the upgrade of the package.  I wonder if that's the best
> > choice.  Many packages can support multiple database instances, so it
> 
> yes, it's by design this way.  this way if something goes wrong,
> the admin knows about it immediately, and has a chance to fix things
> (there's also an option to ignore the problem and fix it later).

One of the reasons this approach concerns me is that if someone wants
to subequently upgrade a database, either because they have multiple
instances or because they are in a situation like mine, there is no
obvious way to do it.  I gather from above that running the scripts
manually is about right if you get the user and choice of database
right.  But I gather dbconfig can do more than execute sql scripts on
upgrade, and, again, there's no obvious way to access this
functionality outside of package install/upgrade.

> 
> since dbconfig-common doesn't currently support multi-instance
> databases, i'm not too concerned on how it handles an upgrade
> for a multi-instance database.  that is, if someone's in that situation,
> they've already >= some of the setup manually, so they can do >= some
> of the upgrade manually too.
> 
> that said, one of the things on my TODO is multi-instance support...

As I found, it's not hard to end up in the mult-instance and
multi-version scenario.  However, I did paranoically refuse an
automatic upgrade at one point, so maybe the situation is not that
common.

...

> > DOCUMENTATION
> > =============
> > 
> > dbconfig doesn't seem to have any user-level (really, admin-level)
> > documentation; the existing documents are for developers of other
> > packages.  Maybe that's OK, since it's supposed to "just work."
> > However, these problems did have me hunting around for such
> > documentation.
> 
> the thing is that dbconfig-common doesn't have tools that the admin
> can use, thus there isn't much to document.  the primary goal of
> this project wrt the "local admin" is to provide something that works
> with the standard package installation process and that doesn't require
> any knowledge about extra cmdline tools (or even the database foo)
> besides the package management tools themselves.
> 
> that said, i'm not against abstracting out some of the code in question
> to external scripts.  for example, 
> 
> 	dbc-upgrade-package <package> <oldvers> <newvers>
> 
> seems like something that would be nice to have.  

As I said earlier, some hooks from outside, or at least discussion of
how to run fromm outside, seem likely to be very useful.  However, it
may not be trivial to do so safely, as I imagine some package upgrade
scripts might do things that really should only be done once.

I really appreciate the info; it gives me what I need so I can proceed
(cautiously).  Also, one of the bacula maintainers seems to be back in
action.


Ross