Crackpot Ideas

There was an interesting post to the Oracle-L mailing list today about using OS packages in cluster database environments.   A quick snippet from the post:

“We typically repackage database binaries as RPMs for wide-scale deployment. Most of the clusters we have currently utilize a CFS. Support scripts are installed onto the CFS with a tarball and we arbitrarily pick a node to install the database server package onto the CFS. The other nodes don’t know that the database package is installed and the OS package inventories across the cluster are out of sync."

So, there’ s a couple of things about this.  Most OS packaging systems use the same general structure – you have the “content”, which is basically a tarball of files that are going to be dropped somewhere on the filesystem.  Then there’s a series of scripts that can be built into the package – typically pre-install, post-install, pre-uninstall, post-uninstall.  This lets you add some logic, start services, etc. etc.

But there’s limitations – typically you can only install one instance of a package on a server, any software that can support multiple installs on a box doesn’t map well to an OS package without making different packages for each install.   Oracle, for example – it’s common to install multiple ORACLE_HOMEs per machine to run different databases.  When your binary install is an RPM, you can only drop one copy of the binaries on a system.

The other limitation is that OS packages are all-or-nothing things – they get very unhappy when they expect to install software and find the software already there. So on a clustered filesystem, when you install the package on the first node, the install on the second node has problems becaue it finds the files already on the CFS.

Here’s my response to the post – in effect, I said, “you shouldn’t use OS packages to bundle database software”, but I tried to be a little more helpful than that.