On 26 April 2011 15:06, Peter Gronbech <[log in to unmask]> wrote:
> Can anyone offer advice to Krishan please.
> Thanks Pete
>
> --
> ----------------------------------------------------------------------
> Peter Gronbech Senior Systems Manager and Tel No. : 01865 273389
> GridPP Project Manager Fax No. : 01865 273418
> Department of Particle Physics,
> University of Oxford,
> Keble Road, Oxford OX1 3RH, UK E-mail : [log in to unmask]
> ----------------------------------------------------------------------
>
>
> Hi All,
> We are currently upgrading our SE (SE_dpm_mysql) and are having
> some problems when running yaim. We are seeing the following two errors
> when running yaim
>
> /opt/glite/yaim/bin/yaim -c -s EFDA-JET-site-info.def -n SE_dpm_mysql
>
>
> 1. ERROR 1044 (42000) at line 1: Access denied for user
> 'root'@'localhost' to database 'dpm_db'
>
> our DPM_HOST, MYSQL_PASSWORD, DPM_DB_PASSWORD are defined in our
> site-info.def file
>
That's a bit odd. Can they log into the database themselves as root?
They need to check what the access permissions are for the root user
on the database. (Is the MySQL server on the same host as the DPM?)
>
> 2. Error while upgrading DPNS schema
>
> INFO: Upgrading DPNS schema from 300 to 310
> DBD::mysql::db do failed: Duplicate column name 'banned' at
> ./cns-db-300-to-310 line 14.
> Issuing rollback() for database handle being DESTROY'd without explicit
> disconnect().
> ERROR: Error upgrading DPNS schema
> ERROR: Error during the execution of function: config_DPM_upgrade_mysql
> ERROR: Error during the
> configuration.Exiting. [FAILED]
> ERROR: One of the functions returned with error without specifying
> it's nature !
>
This happened because the schema update had previously been attempted
(hence the banned column existing), but the final steps of altering
the schema version encoded in the database failed (so YAIM doesn't
know that the schema was updated and tries to update it again the next
time it's run).
There was some discussion about this in the dpm-user-forum list (and
I've previously mentioned it to the storage group), the summary of
which is: some older versions of DPM used different names for the
columns that hold the schema version (major_number instead of major,
etc), which causes newer schema updates to fail to update the schema.
You can fix this by doing:
USE cns_db;
ALTER TABLE schema_version CHANGE major_number major INTEGER(11);
ALTER TABLE schema_version CHANGE minor_number minor INTEGER(11);
ALTER TABLE schema_version CHANGE patch_number patch INTEGER(11);
to fix the table names, and then:
UPDATE schema_version SET major = 3, minor = 1, patch = 0;
to set the schema to the version it should be (since the banned column exists).
Sam
>
> Have anybody come across these issues, while upgrading?
>
>
> Many Thanks
>
>
> krishan
>
|