Because it is possible that the newer version may be deployed over an existing 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.
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 dcache billingbilling=>drop table databasechangelogbilling=>drop table databasechangeloglockbilling->\q[root] #
and then restarting the domain.
Note
If the billing database already exists, but contains tables other than the following:
[root] #psql -U dcache billingbilling=> \dt List of relations Schema | Name | Type | Owner -------+-----------------------+-------+----------- public | billinginfo | table | dcache public | billinginfo_rd_daily | table | dcache public | billinginfo_tm_daily | table | dcache public | billinginfo_wr_daily | table | dcache public | databasechangelog | table | dcache public | databasechangeloglock | table | dcache public | doorinfo | table | dcache public | hitinfo | table | dcache public | hitinfo_daily | table | dcache public | storageinfo | table | dcache public | storageinfo_rd_daily | table | dcache public | storageinfo_wr_daily | table | dcache 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 dcache. 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.