The database capability for billing/accounting is not new to version 2.2. What has changed is the way it is managed. In particular, there is now an abstraction layer (DataNucleus) above the actual database (Postgres) which makes the passage from Java to SQL cleaner and less implementation-dependent. Moreover, updates to the database are handled by a change-management library (Liquibase). The latter is responsible for building the database schema referred to above.
Because it is possible that the newer version may be deployed over an existing 1.9+ installation which already uses the billing database, the Liquibase change-set has been written in such a way as to look for existing tables and to modify them only as necessary (version 2.2 adds several indices, functions and triggers, as well as a set of aggregate tables, in order to optimize the creation of histogram plots).
If you start the domain containing the billing
service over
a pre-existing installation of the billing
database, depending on what was already there, you may observe
some messages like the following in the domain log having to do with the logic
governing table initialization.
Example:
INFO 8/23/12 10:35 AM:liquibase: Successfully acquired change log lock INFO 8/23/12 10:35 AM:liquibase: Reading from databasechangelog INFO 8/23/12 10:35 AM:liquibase: Reading from databasechangelog INFO 8/23/12 10:35 AM:liquibase: Successfully released change log lock INFO 8/23/12 10:35 AM:liquibase: Successfully released change log lock INFO 8/23/12 10:35 AM:liquibase: Successfully acquired change log lock INFO 8/23/12 10:35 AM:liquibase: Reading from databasechangelog INFO 8/23/12 10:35 AM:liquibase: Reading from databasechangelog INFO 8/23/12 10:35 AM:liquibase: ChangeSet org/dcache/services/billing/ db/sql/billing.changelog-1.9.13.xml::4.1.7::arossi ran successfully in 264ms INFO 8/23/12 10:35 AM:liquibase: Marking ChangeSet: org/dcache/services/ billing/db/sql/billing.changelog-1.9.13.xml::4.1.8::arossi::(Checksum: 3:faff07731c4ac867864824ca31e8ae81) ran despite precondition failure due to onFail='MARK_RAN': classpath:org/dcache/services/billing/db/sql/ billing.changelog-master.xml : SQL Precondition failed. Expected '0' got '1' INFO 8/23/12 10:35 AM:liquibase: ChangeSet org/dcache/services/billing/db/sql/ billing.changelog-1.9.13.xml::4.1.9::arossi ran successfully in 14ms INFO 8/23/12 10:35 AM:liquibase: Successfully released change log lock INFO 8/23/12 10:35 AM:liquibase: Successfully released change log lock
Anything logged at a level lower than ERROR
is
usually entirely normal. Liquibase regularly reports when the
preconditions determining whether it needs to do something are not
met. All this means is that the update step was not necessary and
it will be skipped in the future.
If, on the other hand, there is an ERROR
logged
by Liquibase, it is possible there may be some other conflict
resulting from the upgrade (this should be rare). Such an error
will block the domain from starting. One remedy which often works
in this case is to do a clean re-initialization by dropping the
Liquibase tables from the database:
[root] #
psql -U srmdcache billing
billing=>drop table databasechangelog
billing=>drop table databasechangeloglock
billing->\q
[root] #
and then restarting the domain.
Note
If the billing database already exists, but contains tables other than the following:
[root] #
psql -U srmdcache billing
billing=> \dt List of relations Schema | Name | Type | Owner -------+-----------------------+-------+----------- public | billinginfo | table | srmdcache public | billinginfo_rd_daily | table | srmdcache public | billinginfo_tm_daily | table | srmdcache public | billinginfo_wr_daily | table | srmdcache public | databasechangelog | table | srmdcache public | databasechangeloglock | table | srmdcache public | doorinfo | table | srmdcache public | hitinfo | table | srmdcache public | hitinfo_daily | table | srmdcache public | storageinfo | table | srmdcache public | storageinfo_rd_daily | table | srmdcache public | storageinfo_wr_daily | table | srmdcache billing->\q
[root] #
that is, if it has been previously modified by hand or out-of-band
to include custom tables not used directly by dCache, the
existence of such extraneous tables should not impede dCache
from working correctly, provided those other tables are
READ
-accessible by the database user for
billing, which by default is srmdcache
. This is
a requirement imposed by the use of Liquibase. You thus may need
explicitly to grant READ
privileges to the
billing database user on any such tables if
they are owned by another database user.